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I. INTRODUCTION 



A, PREFACE 

Look around and you will see evidence that computers have 
become part o-F our daily lives- Today, computers are common 
place in industry, government, science, politics, and even 
in our homes. As more and more organi zat i ons use computers for 
their needs, it is necessary to use modern, systematic, and 
cost effective approaches for software solutions to their 
problems. In recent years these software solutions have clear- 
ly been motivated by the database systems approach, which is 
widely used in most organi zat i ons- 

Database technology today, plays a central role in the 
computer world for the facilities and data handling capabi- 
lities they provide. 

During the last decade the cost of labor has been increa- 
sing steadily with direct consequence being the parallel 
increase of the software costs. Meanwhile the cost of computer- 
hardware has decreased dramat i cal 1 y . As David Kroenke puts it, 
'The computer industry has developed the equivalent of a $2.50 
Rolls Royce that gets 2,000,000 miles per gallon CRef. 1: 

p. n. 

Thus, simply stated, software has become more expensive as 
computer hardware has become cheaper- In 1960, the ratio of 
hardware over software expenditures was approx i matel y 80 
percent hardware cost to 20 percent software cost- By 1980, 
the ratio was reversed- By 1990, software costs will account 
for more than 90 percent of the amount spent on computing 
systems CRef- 2: p. 81- 

The above consi derat i ons lead us to select systems that 
achieve the best utilization of the software, and thus 
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motivated system designers to build advanced database systems 
in order- to decrease software cost and obtain maKimum benefit- 

B, COMPUTERS IN THE HELLENIC ARMY 

The leadership of the Hellenic Army, realizing the use- 
fulness of computers, introduced them into the Army in the 
1970 's. Today, most of the tedious and error prone bureau- 
cratic manual procedures are automated, and the computer is 
used efficiently in data processing and decision making- Of 
course there are a lot of procedures, especially in the area 
of personnel management, which have not been automated yet. 
One of these procedures which is still performed manually is 
the annual reassignment processing of officers in each Branch 
of the Hellenic Army General Staff (HAGS). The automation of 
this job constitutes the topic of this research. 



C. DATABASE SYSTEMS VS MANUAL SYSTEMS 

The top management in every organization , and in our case 
the Branch Directors of the HAGS, need accurate and timely 
information in order to make fast and better informed 
decisions. 

Currently, all information required by the Director for 
scheduling and processing annual assignments of his officers 
is handled manually by the staff of the Directorate. This 
results in tedious and time-consuming operations, which are 
somet i mes inaccurate. 

Because of the complicated character of this job, and the 
continuous changes pertaining to personnel and the associated 
data, it is extremely difficult for the staff personnel to 



process this job- Further, the Branch Director -Frequently does 
not have the necessary information to make rapid decisions- 

The above problem could be overcome by developing and 
implementing an automated personnel database system- 

The development and implementation of a personnel database 
processing system would provide the following advantages over 
the existing manual system: 

1- Improved productivity, i-e- fewer people can do the same 
job. This is very important since we can reduce the 
staff personnel involved in the manual system, and use 
them for other productive tasks- 

2. Speed, which is very important for a decision-oriented 
processi ng envi ronment - 

3- Reduced tedium- Large volume repetitious jobs can be 
processed easily- 

4. Improved quality of “decisions- Up-to-date data/ 
information can be made available to decision makers- 



D. GENERAL OVERVIEW OF A DATABASE PROCESSING SYSTEM 

In this section some definitions and basic database 
terminology are provided, followed by a summary of database 
architecture and types of data models- A detailed discussion 
of the data models is beyond the scope of this thesis, but a 
brief overview is important as an introduction to dBASE III- 

1. Definition and Basic Terminology 
a. Database 

A shared collection of interrelated data designed 
Xo meet the varied information needs of an organi zat i on . 
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b. Database Management System (DBMS) 

A so-Ftware system that carries out all user- 
requests -For data- User requests may be an update, a delete or 
a retrieval operat i on/tunct i on . 

c. Database System 

A system to record and maintain in-Formation that 
is signi-Ficant to organization in the decision making process- 
It is also called In-Formation System. 



d. Data De-Finition Language (DDL) 

A specialized language used -For the description o-f 
the database (records and data-items). This description ie 
stored in the Data Dictionary maintained by the DBMS. 



e. Data Manipulation Language (DML) 

A programming language used to -Formulate queries 
or to write application programs -For data manipulation. It is 
also called Host Language or Query Language. 

■F. File (or Entity Set) 



An organized collection o-F records representing 
entities o-F the same type. 



g- Record 

A unit O-F data represent i ng a particular entity o-F 
a -File. It consists o-F a number o-F interrelated data elements. 
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h. 



Field 



A subdivision of a record 
i nf ormat i on . It is the smallest unit of 



contai ni ng 
named data- 



a unit 



of 



i - Key 

An attribute (field) or a set of attributes whose 
value uniquely identify each entity in a file. 



j. Relationships 



A relationship among entity sets (files) is simply 
an ordered list of entity sets. Relationships are classified 
into the following three categories according to how many 
entities from one entity set can be associated with how many 
entities of another entity set CRef. 3: p. 14D: 

(1) One— to— one Relationship . For an entity A in either set 
there is e;<axtly one associated entity B of the other 
set. Eg. Suppose that in a database we have the entity 
sets DEPARTMENT and HEAD_OF_DEPARTMENT. The two sets 
form a one— to— one relationship since each department 
has only one head and each head can belong only to one 
department. CRef. 3: p. 153 

(2) One— to— many Rel at i onshi p . For an entity A in either set 
there are (possibly) many associated entities of the 
other set. For example the entity sets ORDER and 
CUSTOMER form a one-to-many relationship since each 
order is related with a specific customer, while a 
customer may be related with more than one orders. 

(3) Many— to— many Rel at i onshi p . There are no restr i ct i ons on 
the sets of pairs of entities that may appear in a 
relationship set. For example the entity sets PRODUCT 
and RAW^MATERIAL form a many— to— many relationship since 
a product may be built from more than one raw material 
and a raw material may be used to build more than one 
type of product. 
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2 . 



Archi tecture o-f a Database System 



It is obvious that between the computer, dealing with 
bits, and the end user sitting in -front of a terminal managing 
information, there can be many levels of abstraction. The 
database architecture is divided into three different levels 
of abstraction: internal, conceptual , and eKternal. In Figure 
1 we can see the standard view-points regarding the three 
levels of a single database, which may be one of many data- 
bases using the same DBMS software- CRef. 3: p. 63 

The internal view is the physical database, and resi- 
des permanently on secondary storage devices, such as disks 
and tapes. It should be emphasized that only the physical 
database exists. We may view the physical database itself at 
several levels of abstraction, ranging from that of records 
and files in a programming language such as COBOL, through the 
level of logical records, as supported by the operating system 
underlying the DBMS, down to the level of bits and physical 
addresses on storage devices- 

The conceptual view (or schema) is an abstraction of 
the complete picture of an organi zat i on . A DBMS provides the 
Data Definition Language to specify the conceptual scheme. 

The external view (or subschema) is an abstract model 
of a portion of the conceptual view- More commonly it is cal- 
led user view- 

3. Database Systems vs Tradi ti onal File Systems 

Database technology allows an organi zat i on ' s data to 
be processed as an integrated whole. It reduces the need of 
creating and maintaining separate files for separate applica- 
tions and permits users to access data more natural 1 y. CRef . 1: 
p. 13 
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Fig. 1. Levels o*f Abstraction in a Database System. 



To appreciate this concept , consider the systems shown 
in Figure 2. These are three traditional -file processing 
systems. Each file is considered to exist independently, and 
each application program maintains its own files. Also there 
is no sharing of data among different application programs. 

Figure 3 shows a database processing system. The files 
from the previous approach have been integrated into a data- 
base which is processed indirectly by the application prog- 
rams. The new system can perform all the old functions, but 
the programs cal 1 upon the DBMS to access the database. The 
DBMS acts as a data librarian. It stores and retrieves data. 
Besides the data it stores in the database, the DBMS also 
stores a description of the format of the data. This is neces- 
sary in order for the DBMS to be able to perform its function. 
CRef. 1: p. 3D 
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Fig. 2. File Processing Systems. 
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Fig. 3. Database Processing System. 



The database processing approach is more beneficial 
than the traditional file processing approach for the fol- 
lowing reasons: 
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a- Integrates data into a single database. This -Feature is 
extremely important because it enables more in-formation 
to be produced -from a given amount o-F data. This is 
because DBMS allows processing of any combination of 
data stored in the database, and thus we can obtain more 
information. In the file processing system the 
combinations of data that can be performed are limited, 
since data is physically partitioned, and hence the 
amount of inf ormation obtained is limited. CRef. 1: p. 3D 

b. Minimizes data redundancy. Separate and redundant data 
files are integrated into a single logical structure. 
This means that • a data item is recorded once, while in 
the file processing system the same information can be 
repeated in different files. 

c. Provides data consistency. Because the data redudancy is 
controlled, ti;c?r*e is less chance of i nconsi stenci es - 
This is not true for a file processing system, since the 
data redundancy is uncontrol 1 ed. 

d. Allows sharing of data. Data can be shared by many 
application programs via DBMS. In the file processing 
approach, since every application has its own private 
files, there is little opportunity to share data from 
other application programs' files. 

e. Allows enforcement of standards. Since data is repeated 
only once, maintaining a standard is a lot easier. 

f. Facilitates the development of new appl ications. There 
is no need for designing, building, and maintaining anew 
separate files for new appl i cat i ons , while in the file 
processing approach , usually a new application must be 
build from scratch. 

g. Provides uniform security, privacy, and integrity 
controls. Some of those controls are provided directly 
by the DBMS (concurency control ) , and others are 
specified by the user during the database definition 
(integrity rules) and the program development (security 
constrai nts) . This is an immediate benefit from the 
sharing and integration of data. 

h. Creation of program/data independence. DBMS isolates any 
changes in file formats, record structure, etc. from 
application programs. Therfore only the DBMS and those 
programs that use the changed data element need to be 
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modified. In the file processing systems, programs 
interface directly with files and hence the structure 
of files is distributed aiCirass the programs- This 
distribution creates problems when a file is changed. 
CRef. 1: p. 43 

i- Facilitates data accessi bi 1 i ty and responsi veness- DBMS 
provides an interactive interface to database by query 
1 anguage- 

j- Reduces program maintenance. This is a direct 

consequence from the program/data independence feature- 
This is not true for the file processing approach where 
any change in a datafile will necessitate a (possibly 
major) change in programs. 



4. Data Model s 

A model is a representat i on of real world objects, 
events, and their associations in a mathematical form- 

A data model is an abstract representat i on of the data 
about entities, events, activities, and their associations- 
The purpose of a data model is to represent data in an 
Linderstandabl e way. The three most important data models in 
use today are the network, hierarchical and relational- These 
models are also used to categorize DBMS products- CRef- 3: 
p. 183 

a. Network Data Model (NDM) 

A network data model represents data as a set of 
record types and pairwise rel at i onshi ps between record types 
(Figure 4)- Relationships that involve more than two record 
types are not directly permitted- 

The basic data structure used in a network data- 
base is the graph- The links in the graph are bi d i rect i anal , 
allowing us to travel either from many to one or from one to 
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many. The process o-f -following the graph links, or more 
generally, rel at i onsh i ps is called navigation CRe-F, 3: p. 30]. 
Navigation allows us to search the database and per-form the 
basic operations (retr i eve , i nsert , modi-fy, or delete) - 

The DBMS in a network database processing system 
supports the use o-f multiple one-to-many or many— to~one 
rel at i onsh i ps between the same pair o-f record types, but can- 
not support directly the use o-f many-to-many relationships. 



COURSE TEACHER 




Fig. 4. Network Data Nodel 



b. Hierarchical Data Model (HDM) 

In the Hierarchical Data Model organizations are 
viewed as a hierarchy o-f positions- A hierarchical database 
consists o-f one or more trees and each tree consists o-f a 
hierarchy o-f records (Figure 5). Hierarchical data models are 




considered as a special case of the network data model since 
the tree structure is a special case of the graph. 

The basic operation on a hierarchical database is 
a tree walk, that is, given a node of the database instance, 
we can scan all of the descendants of a given logical record 
type- This allows us to insert new records, retrieve, modify, 
or delete existing records- 

The above operation is uni di rect i onal , that is, 
the links in the tree proceed from parent to child only 
CRef. 3: p. 323. For this reason HDM is considered inefficient 
in supporting many— to— one relationships. 



DEPARTMENT 




Fig. 5. Hierarchical Data Model - 



c. Relational Data Model (RDM) 

A relational data model differs from NDM and HDM 
in archi tecture- The data are represented as a collection of 
relations- Intuitively, a relation is a two dimensional table 
(Figure 6) representing a file- The rows of the relation are 
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the file records. Rows sometimes are called tuples of the 
rela tion. Each column contains values about the same attri- 
bute (field), and has a distinct name, i.e., the name of the 
attribute. The sequence of the rows is immaterial CRef. 1: 
p. 1963. 

The set of attribute names for a relation is cal- 
l ed the relation scheme. For the eKample in Fig. 6, the 
relation scheme for the relation PRODUCT is ^PRODUCT#, NAME, 
PRICE>. The collection of relation schemes used to represent 
information is called a (relational) database scheme, and the 
current values of the correspondi ng relations is called the 
(relational) database. CRef. 3: p. 213 

The principal advantage of an RDM is data flexibi- 
lity. Relationships need not be predefined. We can join 
PRODUCT tuples with ORDER tuples (Fig. 6), without having to 



ORDER relation - PRODUCT relation 



QRD# 


DATE 


PROD# . 


QUANT 


0870 


01/16/86 


0100 


25 


1001 


01/21/86 


0120 


8 


1025 


01/25/86 


0215 


10 


1236 


02/12/86 


1025 


5 


1142 


02/15/86 


1132 


3 



PROD# 


NAME 


PRICE 


0 1 00 
0110 
0 1 20 
0215 
1025 
1100 
1132 
1140 


CHAIR 

TABLE 

BOOKCASE 

DRESSER 

SOFA 

ARMCHAIR 

BED 

COUCH 


25 . 00 

125. 00 

1 20 . 00 

380 . 00 

289 . 00 

208. 00 

105. 00 

430 . 00 



Fig. 6. Relational Data Model 



predefine the rel at i onshi ps in the design. The RDM can support 
the use of all types of rel at i onshi ps. 



The second advantage is that the way o-F arranging 
the data is simple and more understandabl e to humans than the 
way o-f arranging data in the NDM and HDIi, since the table 
structure is simpler than the graph and tree structures, 

Another advantage is that query languages provided 
for relational database processing systems, permit data to be 
manipulated as groups and not procedurally as one record at a 
t i me- 

For the above reasons, relational DBMS have become 
very popular, although it is the youngest of all DBMSs in 
the computer community. 



E- dBASE III CONCEPTS 

Recently, database management systems built for micro- 
computers have become very popular. They provide an 
inexpensive and easy way for developing database systems for 
applications like general personnel, accounting, and inventory 
control . 

dBASE III is a relational database management system for 
mi crocomputers. It contains its own programming language, 
permitting a user to develop extremely powerful and complex 
application programs, dBASE III is used as the DBMS in the 
design and development of an automated officer assignment 
database system, 

1, Features of dBASE III 

a. Program/data independence. Changes in file structure do 
not affect application programs, 

b. Data can be easily updated. 
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c- Besides the known data types (character, numeric, and 
logical), it provides the date data type -for managing 
dates, and memo data type -for managing long passages 
o-f text- 



d- Saves information as disk -files in 9 specialized -formats 
each serving a speci-fic dBASE III processing need. 
CRef. 5: p. 2-5D 

e. Sorting and indexing capabi 1 i t i es. 



f- Creation and printing o-f -formatted reports, 
g- Date arithmetic- 

h- Built-in high level 1 anguage , whi ch is extremely power-ful 
and supports structured programming- 



i- Allows inter-facing with other so-ftware systems, such us 
SuperCalc, Symphony, WordStar and Basic- CRef. 43 



2. Limitations o-f dBASE III 



a. Each database -file can have up to 1 billion records 
maximum. The maximum size of each file is 2 billion 
bytes. 

b- Allows a maximum of 128 fields in each record with their 
combined widths up to a maximum of 4,000 characters- 

c- Allows you to have up to 10 database files open at the 
same time, or 15 files of all types- You can have 7 open 
index files and 1 format file per active database file. 

d. Filenames can be up to 8 characters long and fieldnames 
can be up to 10 characters long- 

e- The maximum number of active memory variables is 256- 
The total number of bytes for memory variables is 6,000- 

f- Execution of dBASE III programs is slower than compiled 
progr ams- 

A1 1 the above values may be limited by the 
computer hardware conf i gurat i on - CRef. 5: p. 2—23 
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II. ANALYSIS 



Analysis is the study o-f a problem prior to taking some 
action. In our case, analysis re-fers to the study o-f the 
existing problem in order to derive the required in-formation 
which will enable us to decide whether a database system 
approach can provide an e-f-ficient and economical solution to 
our problem or i-f it will become part o-f the problem. 



A. PROBLEM DEFINITION 

As we stated earlier, the operations required -for sche- 
duling the annual assignments o-f the o-f-ficers in each Branch 
o-f the Hellenic Army General Sta-f-f (HAGS) are per-formed 
manually by the sta-f-f o-f each Branch. This results in tedious 
time-consuming operations and i ne-f -f i ci ency . In addition, the 
Branch Director may not be able to make -fast decisions 
concerning personnel management due to the lack o-f timely and 
accurate in-formation. Further, the volume o-f transactions in 
every big organization and especially in the army, pertaining 
to personnel management, is getting larger and larger, which 
means that additional personnel is required to per-form the 
above job, leaving other critical positions unmanned. 

For a solution to the above de-finition o-f the problem we 
ask the question 'can a database system provide a more e-f- 
-ficient and economical solution’?'. In order to answer this 
question we must be aware o-f how a Branch is organized, what 
is being done, how -frequently does this job occur, and how 
great is the volume o-f transact i ons . 
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1 . Qrqani zat i on Qvervi ew 



a. Branch Organization 

The Hellenic Army General Staf-f is organized into 
three major parts: Arms, Services, and Sta-f-f. The relation 

o-f these parts to the HAGS organization is summarized in 
Figure 7. 




Fig. 7- Organization Chart o-f the HAGS- 



Each Arm or Service (we will call them simply 
Branches), is responsible for the operational readiness and 
managerial aspects of the units which are part of the Branch - 
Each Branch is organized into subordinate Com- 
mands, Staffs, and Units- The number of units var i es from 
Branch to Branch , depending on the mission and special 
character istics of each Branch of the Army- 

In order to provide a concrete example of a branch 
organization we will use the Artillery Branch as the model for 
this research- Figure 8 summarizes the relation of the com- 
mands, staffs, and units to the Artillery Branch organ! zat i on - 
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Fig. 8- Organization Chart of the Artillery Branch. 



In Table I we provide a detailed list of the 
Artillery echelons. There are four categories of units: 
Staffs, Schools, Training Centers, and Combat Units. Also 
units are character ized as A-type, B-type, or C-type according 
to their operational readiness. The operational readiness 
determines the level of manning for each unit. The names, 
number of units, and the manning level provided below are 
figurative for security reasons. 




Table I- Artillery Echelons 



UNIT : UNIT 

NAME ! DESCRIPTION 


UNIT 

CATEGORY 


UNIT 

TYPE 


ABD/HAGS I Arti 1 1 ery Branch Directorate 


Sta-f-f 


A 


AS {Artillery School 


School 


A 


ARTC I Arti 1. Recruit Training Center 


Train- Center 


A 


GMB {Guidance Missile Battalion 


Combat Unit 


A 


AC/1 AC list Army Crop Artil- Command 


Sta-f-f 


A 


11 FA/ABIField Anti-Air Artil. Battal . 


Combat Unit 


A 


12 HAB {Heavy Artillery Battalion 


Combat Unit 


A 


13 OB {Observation Battery 


Combat Unit 


A 


AC/ll ID! 11th In-f. Div. Artil. Command 


Sta-f-f 


A 


111 FAB {Field Artillery Battalion 


Combat Unit 


A 


112 FAB {Field Artillery Battalion 


Combat Unit 


A 


113 MHAB { Med i urn— Heavy Artil. Battalion 


Combat Unit 


A 


AC/12 ID{12th In-f- Div. Artil- Command 


Ssta-f-f 


B 


121 FAB {Field Artillery Battalion" 


Combat Unit 


B 


122 FAB {Field Artillery Battalion 


Combat Unit 


B 


123 MHAB { Med i um-Heavy Artil. Battalion 


Combat Unit 


B 


AC/2 AC {2nd Army Crop Artil. Command 


Sta-f-f 


B 


21 FA/AB{Field Anti-Air Battalion 


Combat Unit 


C 


22 HAB {Heavy Artillery Battalion 


Combat Unit 


c 


23 OB {Observation Battery 


Combat Unit 


c 


AC/21 ID {21st In-f- Div. Artil. Command 


Sta-f-f 


B 


211 FAB {Field Artillery Battalion 


Combat Unit 


B 


212 FAB {Field Artillery Battalion 


Combat Unit 


B 


213 MHAB { Medi um-Heavy Artil. Battalion 


Combat Unit 


B 


AC/22 ID {22nd In-f. Div. Artil- Command 


Staf-f 


C 


221 FAB {Field Artillery Battalion 


Combat Unit 


C 


222 FAB {Field Artillery Battalion 


Combat Unit 


C 


223_MHAB { Medi um-Heavy Arti 1 - Battal i on 


Combat Unit 


C 



b- 0-f-ficers' Organization 

□tficers come -from two sources, those who have 
graduated -from the Military Academy (MA) , and those who used 
to be warrant o-f-ficers and have been promoted to o-f-ficers- 
They have graduated -from the Non-Commissioned 
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O-f-ficers School 



(NCOS). Further, o-f-ficers are di st i ngui shed according to their 
specialty as commanding o-f-Ficers (all o-f-ficers coming -from the 
Military Academy plus a small number coming -from NCOS), 
technicians, and admi nistrati ve o-f-ficers (o-f-ficers coming only 
■from NCOS) . 

O-f-ficers are assigned to various units according 
to an organization table maintained by each Branch- Table II 
illustrates the organization table o-f the Artillery units- 

2. Descr iption o-f the Present Situation 

One o-f the major responsibilities o-f a Branch is to 
schedule and monitor the assignments o-f the o-f-ficers who 
belong to this Branch- Each o-f-ficer during his career has to 
be assigned to various units and sta-f-f positions in order to 
be equiped with the necessary skills which will quali-fy him 
■for -further pro-f essi onal evolution- For this reason, in each 
Branch o-f the HAGS there exist a mechanism through which the 
Director keeps track o-f the assignments o-f his o-f-ficers- 

A1 1 o-f-ficers through the rank o-f captain are exclu- 
sively assigned to units which are part o-f the correspondi ng 
Branch- However, a small number o-f o-f-ficers, -from the rank o-f 
major and on, are unbound by the Branch and disposed to the 
HAGS to man other sta-f-f units outside the Branch- The number 
o-f o-fficers serving outside the Branch is always -fixed- 

Each Branch schedules and monitors the assignments o-f 
its o-f-ficers up to the rank o-f the Colonel- The assignments 
o-f the Generals are scheduled by the HAGS and they will not be 
discussed here- 
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Table II. Organization Table of the Artillery Units 



I T I OFF I CERS ' D I STR I BUT I ON 



UNIT !Y!06 


05 


04 


03 


02 I 01 


SUM 


IP IMA 


NA 


NA 


NCOS 


NA 


NCOS 


NA 


NCOS IMA 


NCOS 


NAME ! E I C 


c 


c 


C 


T 


A 


c 


C 


T 


A 


c 


C 


T 


AI C 


C_ 


T 


A 


ABD/HA6SI AI3 


4 
























1 








10 


AS ! A I 2 


3 . 




1 


1 


1 


6 


1 






6_ 






I 12 




•~\ 


2 


39 


ARTC I A I 1 


4 


2 


1 


1 


1 


9 














_I 12 




3 


3 


37 


BMB 1 A ! 


^ n 


5 




1 


1 




1 






9 






f 

1 




“T 


3 


30 


AC/1 AC I All 


1 


3 










1 












1 

1 








6^ 


11 FA/ABIAI 


1 


1 








3 




1 


1 


3_ 


1 




1 

1 


1 ,, 






12 


12 HAB !AI 


1 


1 








3- 








3 




1 


1 1 


1_ 






1 1 


13 OB lAI 




1 








1 








3 






1 




1 


1 


7 


AC/11 IDIAIl 


1 


2 


















1 




1 

I 








5 . 


111 FAB I A I 


1_ 


1,_ 








3_ 




1 


i 


2 


1_ 




__ 1 1 


1_ 






12_ 


112 FAB lAI 


1 


1 








3 




1 


1 


2 


1 




I 1 


1 ^ 






12_ 


113 NHABIAI 


1_ 


1_ 








4_ 




1 


1 


3_ 


1^ 




1 1 


1_ 






14 


ac/i2_id:b: i_ 




2 














1 








1 

1 








4 


121 FAB IBI 


1 


1 
















2 




1 


111. 


1 






10 _ 


122 FAB IBI 


1 


1 
















2 




1 


1 1 1 _ 


1, 






10_ 


123 NHABIBI 


1 ,, 


1 








2 


r 


i 


r 








1 1 


1 






1 1 


AC/2d AC I B I 1 


1 


2 


















1 




1 

I 








5 


21 FA/ABICI 


1 _ 


1 








'n 








1_ 




1 


1 I 








7_ 


22 HAB i C ! 


1 


1 








2 












1 


1 I 


1.. 






7 


23 OB I C I 




1 
















1 






1 

1 




1 


1 


4 _ 


AC/21 ID! BI 1 






















1 




1 

1 








4 


211 FAB IBI 


1 


1 








2 








2 




1 


1 1 1 


1_ 






10 _ 


212 FAB IBI 


1,^ 


1 ^ 




















1 


1 I 1 


1_ 






10 , 


213 NHABIBI 


1^^ 


1_ 








2 


r 


1 


1 


2 






_I 1_ 


1 ^ 






11 __ 


AC/22 _ ID! Cl 1 




1 


















1_ 




1 

1 








_3_ 


221 FAB ICI 


1 




1 




















_! 1_ 




1_ 


1 


__8__ 


222 FAB 1 C 1 


1 




1 






2 








1_ 






1 1 




1 


1 


8 


223 MHABICI 


1_ 


1_ 








2 


1 






1_ 




1 


1 1 1__ 








9 


TOTAL I 12 


3" 


39 


4 


3 


3 


60 


6 


6 


T 


48 


9 


8 


8136 


12 


12 


12 


316 



Rank_Codes 
06=Col onel 
05=Lieut. Colonel 
04=Na jor 
03=Captai n 
02= 1st Li eutenant 
01=2nd Li eutenant 



Officers^ _0r i gin 
liA =Ni 1 i tar y 
Academy 

NCOS=Non-Commi ssi oned 
Officers School 



Of f i cers ^ Speci al ty 
C=Commandi ng 
T=Techni t i an 
A=Admi ni strati ve 
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a. Criteria a-f-fecting the Assignments 



The mechanism o-f scheduling the assignments in each 
Branch o-F the HAGS is based on certain criteria. The criteria 
vary -from Branch to Branch depending on the organization and 
special characteristics o-f each Branch- Among those criteria 
we will pick up the common ones in order to keep this 
research more abstract, so that it can be easily applied to 
every Branch with minor modi-f ications. 

Or i qi n . Q-f-ficers coming -from NCOS can never be assigned 
to sta-f-f positions, as well as in units outside the 
Branch . 

(2) Speci al ty ■ Table II, determines the number o-f o-f -f i cers 
assigned to each unit according to their specialty. 

Schools . The only school that can directly a-f-fect the 
assignments is the War College. An o-f-ficer can never 
be assigned to a sta-f-f unit i-f he has not graduated 
-from the War College. Other schools that do not a-f-fect 
the assignments are not discussed here, although they 
may be very important -for other aspects in the decision 
making process. 

(4) Rank . From the Organization Table (Table II) we can 
determine the number o-f o-f-ficers per rank assigned to 
various units. However, there are some simple rules 

governing the assignments which cannot be seen in the 

table and they are stated below. 

(a) All 2nd lieutenants, right a-fter their graduation 

-from the Military Academy, are assigned to the 

correspond! ng Branch-school (Artillery School -for 
our model) -for training (specialization). A-fter 
one year o-f training, all are assigned to the 

Artillery Recruit Training Center (ARTC) in order 
to obtain the necessary training experience. They 
remain one year in the ARTC and then are assigned 
to various combat units. 

(b) All o-f-ficers graduating -from the War College (only 
majors) are assigned to sta-f-f positions (inside or 
outside the Branch) -for at least two years- 
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< 5 ) 



Command T i me . Command time is a requirement tor all 
otticers up to the rank of lieutenant colonel -for 
promotion to the next rank- The minimum command time 

required -for a lieutenant colonel is one year o-f 
service as a Battalion commander- Therefore, each 
Branch during the scheduling o-f the assignments must 
take the command time into consi derat i on , and assign 
the lieutenant colonels who have not completed this 
requirement as Battalion commanders- Each commander is 
responsible to assign appropriate duties to all his 
subordinate o-f-ficers, so that they can complete the 
required command time -for their rank- 
er) Time of Servi ce i n the Same Unit - For each rank there 
is a minimum and a maximum time an o-f-fi cer can serve in 
the same unit as described below- 

(a) Lieutenants 3-4 years- 

(b) Captain 3-4 years- 

(c) Major 1—3 years- 

(d) Lieutenant colonel 1—3 years 

(e) Colonel 1—2 years 

(7) Q-f-f icers^ Requests - A-fter an o-f-ficer has been assigned 
to a unit -for a year he makes a request -for his next 
assignment- This request is submitted only once during 
each assignment period, except in the case when serious 
reasons dictate the change o-f the request and a need 
-for resubmission- In the request each o-f-ficer states 
his pre-ferences in three areas that he would like to 
serve in during his next assignment- The o-f-ficers' 
requests are examined by the Branch during the 
scheduling o-f the assignments, and in combination with 
the other criteria- I-f there is no con-flict, all 
conditions can be satis-fied. 

(8) Mar i tal Status - This criterion is examined whenever two 
or more o-f-ficers having the same qual i -f i cat i ons request 
the same unit -for their next assignment- In this case 
married o-f-ficers or o-f-ficers having bigger -families are 
given pre-f erence. 

(9) Hi stor i cal Data - Each Branch maintains a record -for 
each o-f-ficer, containing all personal and service data- 
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All assignments o-F an officer are maintained in his 
record, along with the previously mentioned data. This 
data must always be kept up-to-date, because they 
reflect the real picture of an officer and provide 
scheduling personnel with the required information to 
accomplish their task. 



b. Officer Processing Considerations 

Of ficers' * assignments are closely related with the 
promotions. The assignments follow the promotions, which 
usually occur four times a year: for the colonels (March), for 
the lieutenant colonels (April) , for the majors (May) , and for 
the lieutenants/captains (June). After the announcement of the 
promotions by the HAGS, each Branch schedules the assignments 
for the correspondi ng rank and implements them by issuing the 
necessary orders. 

The personnel involved in this job combines all 
the above criteria and determines who of the officers meet the 
requirements for a new assignment and in which unit he must be 
assigned. Usually one fourth of the officers of each Branch 
are moved every year during the assignments. Besides this 
duty, the above personnel are responsible to provide the 
Branch Director and other staff offices of the HAGS all 
requested information concerning the officers of the Branch. 

The number of personnel involved in this job 
varies from Branch to Branch, depending on the volume of the 
officers enrolled in each Branch. In our model usually three 
people are directly involved, one lieutenant colonel, one 
lieutenant, and one civilian. 
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B 



JUSTIFICATION OF A COMPUTERIZED SOLUTION 



From the above discussion, it is obvious that the manual 
processing o-f the o-f-Ficers"' assignments is a very tedious, in- 
e-f-ficient and time-consuming operation- Three people are 
working continuously creating, classifying and updating 
officers' records, scheduling the assignments, and providing 
the Branch Director and HAGS all requested information (lists 
and various reports) concerning personnel management- Further, 
inaccuracies and delays may be introduced in the decision 
making process due to the great volume of required data and 
the complex character of the job- 

A1 1 of the above mentioned problems could be overcome by 
developing and implementing an automated system- 

There are two possible computerized approaches which can 
provide a solution to our problem: the traditional file 
processing approach, and a database system approach- Between 
the two approaches the later is more efficient than the first 
one for the reasons explained previously- Further, the 
implementation of a database system on a mi crocomputer is an 
economical solution, since the expenses for buying the entire 
system (hardware and DBMS) are very low (about $4,000) and 
they can be offset by a reduction of processing personnel 
(from three to one). It is apparent that this system would 
also provide a better quality of services- 

From the above discussion it is evident that a database 
system should be developed and implemented on a mi crocomputer 
for an efficient and economical solution to the officers' 
assignments scheduling problem, as well as, for other problems 
related with personnel management in each Branch of the HAGS- 
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C. SYSTEM GOALS AND REQUIREMENTS 



In order to establish a -framework -for the database system 
devel opment , i t is necessary to speci-fy what we expect -from the 
new system, and what capabilities this system must provide. 

1 . Goals 



Goals are targets -for achievement. The following 
targets must be achieved by the system under development: 

a. It should reduce the personnel involved in the process 
of officers' assignments scheduling by 65 percent- 

b. It should be easy to use by nonprogrammers . 

c. It should be useful. 

d. It should be cost effective. 

e. It should make users' jobs more interesting- 

2. Requirements 

Requirements specify capabilities that a system 
must provide in order to solve the problem. Requirements 
include functional requi r ements , performance r equi rements , and 
requirements for hardware, software, and user interfaces 
CRef. 2: p. 333- The capabilities the new system must provide 
are the following: 

a. Reliability, i.e. it must be able to preform its 
intended functions under stated conditions for a stated 
period of time- 

b. Application development must be easy, cost—ef f ect i ve , 
and fast- 

c. The data can have multiple uses. 
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d. Per-Formance. It must be fully operational 95 percent of 
each 24-hour period. 

e. Response time to user requests (queries) no more than 5 
seconds- 

f. The size of primary memory able to support the system 

must be at least 320K bytes (180K bytes for bBASE III 

system program plus 50K bytes for operating system 
requirements plus 90K for user requi rements) . CRef. 
5 : p . 36 ] 

g. The computer system must be equiped with a 20M byte 

hard-disk for the user files and programs, and at least 

one floppy disk drive for the system program and for 
back-up purposes. 

h. Mai ntai nabi 1 i ty , i.e. software changes must be easy and 
cost-ef f ecti ve. 

i. Security and privacy. 



D . I NPUT / OUTPUT I NFORM AT I ON 

As stated earlier, the system under development can be 
applied to all Branches of the HAGS with minor modi f i cat i ons , 
but for the purpose of this research we will include only the 
Artillery Branch. 

Although in this phase we are not able to specify what the 
exact input and output information will be, we have gained 
some insights and understandi ng from the discussion thus far. 
These thoughts should be taken as hints and guidelines 
concerning system input and output information for the product 
design, but not as rigid requi rements. 

Detailed description of the required input and output 
information will be provided in the design phase. 
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1 



Input Information 



Since the system is intended to deal with officers, 
the required input information should be officers' data- 
Therefore, we must consider the following: 

a. Each officer has a unique serial number, rank, origin, 
specialty, nomination date, promotion date in the 
current rank, and a home city. 

b. Each officer serves in some unit since a certain date 
(enrollment date), and has been assigned a duty- The 
unit is identified by a unique name, has a readiness 
type, and is located in some geographical area of the 
country (city and county). 

c- Each officer has a marital status (single, married, 
divorced, windower, number and age of children, working 
wife) . 

d- Each officer has some education (mi 1 i tar y/non-mi 1 i tar y 
studies) - 

e. Each officer submits a request to the Branch indicating 
three areas he wants to be assigned in his next 
assignment in preference order-’ 

f- Each officer has some historical data (previous assign- 
ments, duties, promotion dates etc. ) - 



2. Output Information 



To meet the above goals and requirements the following 
output information is required: 

a- List of the scheduled officers' assignments by rank 
including serial number, name, rank, source unit, desti- 
nation unit, and date the assignment must take place- 

b- List of any unit including the officers assigned to it, 
their duties, and enrollment date. 

c. List of all Artillery officers in any requested order- 



d. List of officers by rank reflecting their present status 
(rank, unit, duties, command time, marital status, and 
enrollment date). 

e. List of Battalion commanders- 

f. List of all Artillery officers serving outside the 
Branch - 

The above lists will be formatted and issued at any 
time upon request- Besides these lists, the following reports 
will be available: 

a. Service time report for any officer including all units 
he has been assigned to, duties, and enrol 1 ment/di s- 
disenrol 1 ment dates, in chronol ogi cal order- 

b. Officer's status report reflecting his status. 
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III. DESIGN 



The design is a solution— the translation o-f requi rements 
into ways of meeting them CRef. 6: p. 2243- In our case, data- 
base design is the process of developing database structures 
from those formulated in the analysis phase of Branch 
requi rements- The resulting design must satisfy the needs of 
the Branch in terms of completeness, integrity, and 
performance constraints- The design of the system under- 
development includes two steps: the logical (or conceptual) 
design, and the physical design- 



A. LOGICAL (CONCEPTUAL) DESIGN 

Logical design is the process of describing the system 
features, i-e,, the functions, inputs, files, the way the 
files are related to each other in order to form the conceptu- 
al database structure, and outputs in a manner that meets the 
specified requi rements- CRef. 6: p. 2253 



1 . System Functions 



The system under development will perform the fol- 
lowing functions: 

a. Update Operations- This function allows the user to 
insert, modify, and delete records in all the supporting 
files except a few files which will automat i cal 1 y be 
updated, as they will be described later. It is very- 
important for the Branch to keep all the files 
up-to-date since the accuracy of the system will mainly 
depend on the accuracy of the files- Update operations 
take place whenever a transaction comes to the Branch- 
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b. Assignment Processing Operations. This -function will 
per-form the scheduling o-f the o-f-ficers' assignments and 
will take place right a-fter the annual promotions -for 
each rank. Since the criteria applied in the assignment 
scheduling are di-f-ferent -for each rank, as we described 
earlier, this -function will monitor a number o-f sub- 
sequent -functions cor respondi ng one per rank- 

c. Report Generator. This -function is -for retrieving all 
necessary in-formation -from our database upon request. 
The requested in-formation will be displayed on the 
screen and optionally sent to the printer. 

d. Miscellaneous. This -function will include the -following: 



(1) User Author i z at i on Val idation . Whenever a user 
attempts to access the database via the existing 
programs, the system will ask him to enter his 
password. This password will be checked against the 
existing list o*f valid passwords- I-f it is valid, 
the system will allow him to use the database- 
otherwise an automatic exit to the underlying 
operating system will take place. In this way we 
can prevent unauthorized updates and disclosure of 
the database contents- 



<2) User Log . Every time a valid user enters the system 
to do a specific task, a record is automat i cal 1 y 
created containing the user's name, the date and 
time of database access and the kind of task 
performed. In this way we can provide an audit 
trail of who did what on the database and when it 
took place- In case of erroneous updates it will be 
easy to find out what exactly happened. 



(3) Historical 



Data Log . For 

of f i cer nomi nation , 
or death a 
the 



1 ng 

reti rement 
created containing 
rank, type of transaction, 
transaction took place. This 
for for historical purposes. 



each transaction concern- 
promoti on , assi gnment , 
record is automat i cal 1 y 
officer's serial number, 
unit and date the 
file is very useful 



All the above functions will be menu driven. Th« 
functional blocks of the system are illustrated in Figure 9- 
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Fig. 9- Functional Blocks ot the System. 



2. Input Design 

During this step we will specify the manner in which 
data enters the system for processing. In other words we will 
provide the link that ties our system into the users' world in 
a way that guarantees the reliability of the system, avoids 
extra steps and delays, and keeps the process simple. CRef. 6: 
p. 2863 

The most efficient way to achieve the above objectives 
is to design a menu-driven on-line system. A menu is a screen 
of information displayed on the CRT that shows the user what 
functions can be performed and how to select them. 

A main menu and a number of sub-menus will guide the 
user of our system to select and perform the appropriate 
functions in a top-down fashion as described below. 

a. Main Menu Description 

The main menu in Figure 10 shoV^s the options 
available to the user of the database system. Each option is 
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identi-f ied by a number. To invoke a particular option, 
user depresses the key correspondi ng to the desired option 



the 



* MAIN_MENU * 




DATABASE UPDATE: 


1 


ASSIGNMENT PROCESSING;... 




REPORT GENERATOR: 


3 


END OF SESSION; 


4 


EXIT TO DOS: 


5 


Enter your selection -> 





Fig. 10. Main Menu. 



b. Sub-menus Description 



(1) 


Update 


Menu. 


This menu is 


entered 


when 


a 


user 


selects option 


1 from 


the 


main menu, 


As we 


can 


see 


i n 


Figure 11, it provides 


seven 


new options. 


Through 


this 


menu we 



can insert, modi-fy, delete records in the speci-Fied database 



* UPDATE MENU * 



INSERT RECORDS INTO OFFICER FILE; 1 

INSERT RECORDS INTO SCHOOLS FILE: 2 

INSERT RECORDS INTO HISTORIC FILE: 3 

MODIFY RECORDS FROM OFFICER FILE; 4 

MODIFY RECORDS FROM REQUEST FILE: 5 

DELETE RECORDS FROM OFFICER FILE: 6 

EXIT TO MAIN MENU; 7 

Enter your selection -> 



Fig. 11. Update Menu. 
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•files, or exit to main menu. The selection o-f the desired 
records is done by typing the record key o-f the cor respondi ng 
database -file. A-fter selecting a speci-fic record, its 
structure is displayed on the screen and the cursor is 
positioned in the -first element to be updated. Invalid data 
types (numeric, character, logical, or date) are not accepted 
by the system. Thus, the user is protected from typing invalid 
data types. 

(2) Assignment Processing Menu . This menu is dis- 
played in case a user selects option 2 from the main menu 
(Figure 10). This menu provides seven options as it is shown 
in Figure 12- Each function is performed by selecting the cor- 
responding number. The actual input data required for proces- 
sing the assignments are database files, but those files are 
selected by the correspond! ng application programs, so the 
user does not have to worry. 



* ASS I GNMENT _PRQCESS I NG^MENU 

1st LIEUTENANT ASSIGNMENT PROCESSING:--- 1 

2nd LIEUTENANT ASSIGNMENT PROCESSING: 2 

CAPTAIN ASSIGNMENT PROCESSING: 3 

MAJOR ASSIGNMENT PROCESSING: 4 

LIEUT. COLONEL ASSIGNMENT PROCESSING;--- 5 

COLONEL ASSIGNMENT PROCESSING; 6 

EXIT TO MAIN MENU: 7 

Enter your selection -> 



Fig. 12- Assignment Processing Menu- 



^3) Report Generator Menu . This menu is displayed 
when the user selects option 3 from the main menu (Figure 10). 



43 



From this menu a user can select the desired output (list or 
report). Figure 13 shows the details o-f this menu. 



* REPORT GENERATOR MENU * 

LIST OF SCHEDULED ASSIGNMENTS; 1 

LIST OF OFFICERS OF ANY DESIRED UNIT; 2 

LIST OF OFFICERS IN ANY DESIRED ORDER; 3 

LIST OF OFFICERS OF ANY DESIRED RANK; 4 

LIST OF battalion COMMANDERS; 5 

LIST OF OFFICERS SERVING OUTSIDE THE BRANCH; 6 

OFFICER'S SERVICE TIME REPORT; 7 

OFFICER'S STATUS REPORT; 8 

EXIT TO MAIN MENU: 9 

Enter your selection -> 



Fig. 13. Report Generator Menu. 



3. File Desi qn 

To support the above specified functions the following 
files with the correspondi ng structures will be created. The 
names of the files and fields are the ones that will be used 
in our system. 

a. OFFICER File. 

It is the main file containing all required infor- 
mation for each officer. Figure 14 shows the structure of the 
OFFICER file, as well as the explanation of the fields. 
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FIELD 


NAME 


TYPE 


WIDTH 


01 


NAME 


C 


018 


02 


SERNO 


C 


005 


03 


RANK 


C 


002 


04 


NOMYEAR 


C 


002 


05 


SPECIALTY 


C 


001 


06 


SOURCE 


C 


004 


07 


NOMDATE 


Date 


008 


08 


PROMDATE 


Date 


008 


09 


ASWEIGHT 


C 


002 


10 


ORIGCITY 


C 


006 


11 


ORIGCOUNTY 


G 


008 


12 


MARSTAT 


C 


001 


13 


CHILDREN 


N 


001 


14 


WORKWIFE 


L 


001 



F I ELD-EXPL ANAT I ON 

0-f-ficer's name 
0-f-Ficer's serial number 
0-f -f i cer ' s rank 
Year o-f nomination 
Ot-f i cer ' s speci al ty 
0-F-ficer's source (MA,NCOS) 
Nomination Date 
Promotion Date 
Weight -for next assignment 
City o-f o-f-Ficer's origin 
County o-f o-f-fi cer 's origin 
0-f-ficer's marital status 
Number o-f children 
Working wi-fe 



Primary Key : SERNO 

Fig- 14- Structure -for -file OFFICER. 



b. SERVES File 

This -file contains in-formation re-f lecting the cur- 
rent service status o-f each o-f-ficer (unit he is assigned to, 
enrollment date, duty). Its structure and the explanation o-f 
-Fields is shown in Figure 15- 



FIELD 


NAME 


TYPE 


WIDTH 


FIELD-EXPLANATION 


01 


SERNO 


C 


005 


0-f-ficer's serial number 


02 


UNITNAME 


C 


008 


Unit name 


03 


ENROLDATE 


DATE 


008 


Enrollment date 


04 


DUTY 


C 


010 


0-f-ficer's duty 



Primary Key : -CSERNO, UNITNAME> 



Fig- 15. Structure -for File SERVES- 
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c. 



REQUESTS File 



This -file contains o-f-ficers' requests -for their 
next assignment. Figure 16 provides the details of this file. 



FIELD NAME 



TYPE W I DTH F I ELD-EXPLANAT I ON 



01 


SERNO 


. C 


005 


02 


STAFFOFFIC 


L 


001 


03 


SUBMDATE 


DATE 


008 


04 


UNITl 


C 


008 


05 


UNIT2 


c 


008 


06 


UNIT3 


c 


008 



Officer's serial number 
Staff Officer (T or F ) 
Request's submission date 
First requested unit 
Second requested unit 
Third requested unit 



Primary Key : SERNO 



Fig. 16- Structure for File REQUESTS, 



d. ASSIGNED File 



This is a temporary file created during the 
assignment processing, containing information concerning 
theofficers to be assigned to some unit. Details of this file 
areprovided in Figure 17- 



FIELD 


NAME 


TYPE 


WIDTH 


FIELD-EXPLANATION 


01 


SERNO 


C 


005 


Officer's serial number 


02 


RANK 


C 


002 


Rank 


03 


SOURCE 


c 


004 


Source (MA or NCOS) 


04 


SPECIALTY 


c 


001 


Special ty 


05 


UNITNAME 


c 


008 


Unit name 


06 


ASGNDATE 


DATE 


008 


Assignment date 


07 


ASNWEIGHT 


N 


002 


Assignment Weight 



Primary Key: fSERNO, UNITNAME> 



Fig. 17- Structure for File ASSIGNED, 
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e 



UNITORG File 



This -file contains in-formation about the organi- 
zation o-f each unit according to the operational readiness 
type and type o-f echelon as depicted in Figure 18- 



FIELD 


NAME 


TYPE 


WIDTH 


01 


ECHELON 


c 


005 


02 


READINESS 


c 


001 


03 


MAC06 


N 


002 


04 


MAC05 


N 


002 


05 


MAC04 


N 


002 


06 


NC0SC04 


N 


002 


07 


NC0ST04 


N 


002 


08 


NC0SA04 


N 


002 


09 


MAC03 


N 


002 


10 


NC0SC03 


N 


002 


11 


NC0ST03 


N 


002 


12 


NC0SA03 


N 


002 


13 


MAC02 


N 


002 


14 


NC0SC02 


N 


002 


15 


NC0ST02 


N 


002 


16 


NC0SA02 


N 


002 


17 


MACOl 


N 


002 


18 


NCOSCOl 


N 


002 


19 


NCOSTOl 


N 


002 


20 


NCOSAOl 


N 


002 



Primary Key: ^ECHELON, 



F I ELD-EXPLANAT I ON 

Type o-f echelon 
Operational readiness 
MA commanding colonels 
MA commanding It. colonels 
MA commanding majors 
NCOS commanding majors 
NCOS technician majors 
NCOS admi n i strat i ve majors 
MA commanding captains 
NCOS commanding captains 
NCOS technician captains 
NCOS administrati ve captains 
MA commanding 1st lieuten. 
NCOS commanding 1st lieuten. 
NCOS technician 1st lieuten. 
NCOS admin. 1st lieutenants 
MA commanding 2nd lieuten. 
NCOS commanding 2nd lieuten. 
NCOS technician 2nd lieuten. 
NCOS admin. 2nd lieutenants 



Fig. 18- Structure -for File UNITORG. 



-f. UNIT File 

This -file contains in-formation about each unit- 
The Structure o-f the -file and explanation o-f -fields is 
depicted in Figure 19. 
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FIELD 


NAME 


TYPE 


WIDTH 


FIELD-EXPLANATION 


01 


UNITNAME 


C 


008 


Unit name 


02 


CATEGORY 


C 


001 


Unit category 


03 


ECHELON 


C 


005 


Type of echelon 


04 


READINESS 


C 


001 


Unit readiness 


05 


CITY 


C 


010 


City of unit station 


06 


COUNTY 


C 


010 


County of unit station 



Primary Key: UNITDESCR 



Fig. 19- Structure -For File UNIT. 



h. HISTORIC File 



This -File records all major o-F-Ficer's transactions 
which have taken place during his career- Major transactions 
are considered to be the nomination, promotions, assignments, 
retirement, and death- Usually there are more than one entry 
-For each o-F-Ficer in this -File- The structure of the file and 
field eKplanation is shown in Figure 20- 



FIELD 


NAME 


TYPE 


WIDTH 


01 


SERNO 


C 


005 


02 


RANK 


C 


002 


03 


TRANSTYPE 


C 


012 


04 


UNIT 


C 


008 


05 


TRANSDATE 


DATE 


008 


06 


ORDER ID 


C . 


020 



Primary Key: f SERNO , TRANSDATE> 



F I ELD-EXPLANAT I ON 

Officer's serial number 
Officer's rank 
Transaction type 
Unit name 

Date the transaction occured 
Order caused the transaction 



Fig. 20- Structure for File HISTORIC 
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■F 



SCHOOLS File 



This -File contains i n-f ormat i on about military and 
non-military studies o-F the o-F-Ficers, It is possible -For an 
o-Fficer to have more than one record in this file depending on 
the number of schools he has attended. Records are created 
only for officers who studied for at least one year in some 
school. Details are shown in Figure 21. 



FIELD 


NAME 


TYPE 


WIDTH 


F I ELD-EXPLANAT I ON 


01 


SERNO 


C 


005 


Officer's serial number 


02 


SCHOOLNAME 


c 


010 


School —name 


03 


DEGREE 


c 


012 


Title obtained 


04 


OBJECT 


c 


018 


Object of studies 


05 • 


COUNTRY 


c 


010 


Country of studies 


06 


DURATION 


N 


002 


Studies duration in months 


07 


BRADDATE 


DATE 


008 


Graduation date 



Primary Key ; -CSERNO, SCHOOLNAME> 

Fig. 21. Structure of file SCHOOLS. 

i. SELECTED file 

This file contains all officers who have been se- 
lected by the Branch to study in some school for at least one 
year. The structure of the file is shown in Figure 22. 
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FIELD 



NAME 



TYPE 



WIDTH 



FIELD-EXPLANATION 



01 SERNO C 005 Of-Ficer's serial number 

02 SCHOOLNAME C 010 Name o-F the school 

03 SCHOOL YEAR C 002 Year the o-F-Ficer will be 

sent to the school 

Primary Key: -C SERNO > 



Fig. 22. Structure -For File SELECTED 



j. USERLOG File 



This -File records all users' activities on the 
database system. Details o-F the file structure and field- 
explanation are shown in Figure 23. 



FIELD 


NAME 


TYPE 


WIDTH 


F I ELD-EXPLANAT I ON 




01 


USERNAME 


C 


018 


User's name used 


the system 


02 


TASK 


C 


010 


Task performed in 


the system 


03 


PROGRAMS 


c 


10 


Program executed 




03 


LOGDATE 


DATE 


008 


Date of using the 


system 


04 


LOGTIME 


C 


005 


Time of using the 


system 



Primary Key: -CLOGDATE, L0GTIME> 

Fig. 23. Structure for File USERLOG. 



i. USERID File 

This file contains all valid passwords and the 
user's name correspondi ng to each password, as it is described 
in Figure 24. 
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FIELD NAME 



TYPE 



WIDTH FIELD-EXPLANATION 



01 PASSWORD C 006 A predefined password 

02 USERNAME C 018 User's name 

Primary Key: PASSWORD 



Fig. 24. Structure for File USERID. 



4. Conceptual Database Structure 

The files described above are related as illustrated 
in the enti ty/relationship diagram shown in Fig. 25. The 
rectangles represent entity sets (files), and the diamonds 
repesent relationships between entity sets. A relationship is 
also an entity set containing attributes (usually the keys) 
from all other entity sets which are linked together via this 
relationship. As we can see in this diagram each officer 
serves in some unit which has an organization, he requests 
some units to be assigned to in his ne:<t assignment, he may be 
assigned to some unit, he may have studied in some school (s) 
or he may have been selected to study in some school, and he 
has some historic data. The entity sets USERID and USERLOG 
are not linked with the other entity sets in the diagram since 
their function is independent from the other ones. 

Finally, the relational database scheme is presented 
in Figure 26. 
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I USERID - W USERLOG I 

Fig. 25. Entity/Relationship Diagram. 



OFFICER 



SERVES 

REQUESTS 

ASSIGNED 

UNIT 

UN I TORS 



SELECTED 

SCHOOLS 

HISTORIC 

USERID 

USERLOG 



-CNAME, SERNO, RANK, NOMYEAR , SPECIALTY, SOURCE, 
NOMDATE, PROMDATE, ASNWEIGHT , ORIGCITY , ORIGCOUNTY , 
MARSTAT, CHILDREN, WORKWIFE> 

■C SERNO, UNITNAME, ENROLDATE, DUTY> 

TSERNO, WCFINISHED, SUBMDATE, UNITl, UNIT2, UNIT3> 

-CSERNO, RANK, SOURCE, SPECIALTY, UNITNAME, 
ASGNDATE, ASNWEIGHT> 

■CUNITNAME, CATEGORY, ECHELON, READINES, CITY, 
COUNTY> 

-CECHELON, READINESS, MAC06, MAC05, MAC04 , NC0SC04, 
NC0ST04, NC0SA04, MAC03, NC0SC03, NC0ST03 , 
NC0SA03 , MAC02 , NC0SC02 , NC0ST02 , NC0SA02 , MACO 1 , 
NCOSCOl, NCOSTOl, NC0SA01> 

-CSERNO, SCHOOLNAME, SCHOOL YEAR> 

<SERNO, SCHOOLNAME, DEGREE, OBJECT, COUNTRY, 
DURATION, GRADDATET 

■CSERNO, RANK, TRANSTYPE, UNIT, TRANSDATE, 
ORDER I D> 

■CPASSWORD, USERNAME> 

■CUSERNAME, TASK, PROGNAME, LOGDATE, LOGTIME> 



Fig. 26. The Relational Database Scheme 



5. Output Design 



The most important -feature of an information system 
for users is the output it produces. No matter how reliable a 
system is, if it does not produce quality output, users may 
feel the entire system unnecessary. CRef. 6:' p. 2313 

The term 'output' is applied to any information produ- 
ced by a system whether printed, displayed, or spoken. In our 
case the produced output will be printed and/or displayed, 
depending on how the user wants it. Our goal is to design the 
output in such a way that it can be easily read and understood 
by the user. 

As discussed earlier the system output will be lists 
and reports (Figure 13). The length of the output lines will 
be up to BO characters in order to be able to fit either on 
the screen or on the standard S'xll' sheet of paper. 

a. Lists 

(1) List of Schedul ed Assignments . This list is 
produced each time assignment processing function is executed. 
The format of this list is shown in Figure 27. 



ABD/HAGS DATE: 



LIST OF SCHEDULED ASSIGNMENTS FOR (RANK) 



! serial: name 

! NUMBER ! 

20793 Armstrong David K. 
22467 Babbit Almon P. 
20845 Norton Harold G. 



! SOURCE 
AC/1 AC 
AS 

ABD/HAGS 



_UNIT ! DUE 

! DESTINATION ! DATE 
AS 05/21/86 

ABD/HAGS 05/25/86 

111 FAB 05/14/86 



Fig. 27. List of Scheduled Assignments 
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(2) Li st o-f Q-f -f i cers i n Any Desi red Order- This 
List (Figure 28) contains all Artillery o-f-ficers in any o-f the 
■following orders: 

(a) A1 phabet i cal . 

(b) Rank. 

(c) Specialty. 

(d) Rank and alphabetical. 

ABD/HAGS DATE:../../.. 



LIST OF ARTILLERY OFFICERS IN ORDER 



! RANK 1 

1 1 

1 1 


1 NAME 

1 

1 


! SER I AL ! SOU- ! SPEC I - 
! NUMBER ! RCE ! ALTY 


! UNIT 

1 

1 


! MARITAL! 
! STATUS ! 


08 


Down Kenneth R. 


20001 


MA C 


ABD/HAGS 


M 


07 


Calaunan Tend G. 


20017 


MA C 


ARTC 


M 















Fig. 28. List o-f Artillery O-f-ficers in Some Order. 

(3) Li st o-f O-f-ficers o-f a Desi red Unit . This list 
contains all o-f-ficers serving in a speci-fic unit. The -format 
o-f the list is shown in Figure 29. 



ABD/HAGS 



DATE: ../../ 



LIST OF OFFICERS SERVING IN ...(UNIT)... 



: RANK! SERIAL! NAME ! DUTIES ! ENROLLMENT ! 

! ! NUMBER ! | ! DATE ! 

05 20261 Franclin Adams P. Battalion CDR 05/20/84 

04 20768 Ervin Joseph H. Deputy CDR 06/25/85 



Fig. 29. List o-f O-f-ficers o-f a Speci-fic Unit 
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This 

The 



(4) List o-f 0-f-f icers o-f Any Desired Rank , 
list contains all Artillery o-f -f icers o-f any desired rank, 
-format o-f the list is shown in Figure 30. 



ABD/HAGS 



DATE: ../../ 



LIST OF ARTILLERY (RANK)... 



! SERIAL! NAME i SOURCE ! SPECIALTY ! UNIT ! MARITAL! 

! NUMBER! ; ! ! ! ! STATUS ! 



20270 


Bell Richard K. 


MA 


c 


111 FAB 


M 


20273 


Anzini Danniel D. 


MA 


c 


113 MHAB 


M 


20275 


Arise Bruce F. 


MA 


c 


ABD/HAGS 


S 


20277 


Gray Joseph W. 

m 


MA 

m 


c 

m 


AC/1 AC 

m 


D 


• 


m 


m 


m 


m 


• 



Fig. 30. List o-f 0-f-ficers o-f Any Desired Rank. 



(5) Li st of Battal ion Commanders . This List con- 
tains all Artillery Battalion commanders. Details of the list 
are provided in Figure 31. 



ABD/HAGS DATE 



LIST OF ARTILLERY BATTALION COMMANDERS 



RANK 


! NAME 


! UNIT 


! ENROLLMENT DATE 


05 


Cabral David T. 


212 FAB 


06/26/85 


05 


Gray Joseph W. 


112 FAB 


06/18/84 


05 


Franclin Adams P- 


211 FAB 


06/23/85 


05 


Norton Harold G- 


111 FAB 


07/01/84 


05 


Jarecki Edward L 


11 FA/AB 


07/28/85 


• 


. 


. 


. 



Fig. 31. List of Battalion Commanders. 






(6) Li st o-f Q-f -f i cers Serving Outside the Branch . 
This list contains all Artillery o-f-ficers who serve outside 
the Branch. The -format o-F the list is shown in Figure 32. 



ABD/HAGS DATE: 

LIST OF ARTILLERY OFFICERS SERVING OUTSIDE THE BRANCH 

! RANK ! NAME ! UNIT ! ENROLLMENT DATE ! 

07 Billeb James W. HAGS 03/12/85 

06 Wapper Al-frend D. 1 AC 04/20/85 



Fig. 32. List o-f O-f-ficers Serving Outside the Branch, 
b. Reports 

(1) Officer's Servi ce Time Report . This report 
contains a summary o-f the major transactions o-f an o-f-fi cer, 
having occurred during his career. The -format o-f this report 
is shown in Figure 33. 



ABD/HAGS DATE; ../../ 

OFFICER'S SERVICE TINE REPORT 

SERIAL NUMBER: NAME: 

SOURCE; SPECIALTY; ... ORIGIN: 



: DATE ! TRANSACTION TYPE ! RANK ! UNIT ! ORDER ID 

07/20/60 Nomination 01 MA F. 430/21 /621 /NDD 

08/20/60 Assignment 01 AS F. 435/24/321 /ABD 



Fig. 33. O-fficer's Service Time Report. 
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(2) 0-f -f i cer ' s Status Report . This report provides 
all information reflecting an officer's current status. The 
format of this report is shown in Figure 34. 

ftBD/HAGS DATE; 

OFFICER'S STATUS REPORT 



NAME : 

SERIAL NUMBER ; 

RANK : 

SOURCE : 

SPECIALTY : 

NOMINATION YEAR : .. 

MARITAL STATUS : 

CHILDREN : . 

ORIGIN ; 

UNIT ; 

ENROLLMENT DATE : ../../ 

DUTIES : 



Fig. 34. Officer's Status Report. 



B. PHYSICAL DESIGN 

Physical design is the process of transf ormat i on . The 
logical schema is transformed into a working system. This 
transf ormation is done through the tools that are available 
with the DBMS to be used. CRef. 1: p. 188] More specifically, 
during this step we will define the files described above and 
store them into our database, as well as create the programs 
that will manipulate the files through the dBASE III DBMS. 

The database schema or more simply the files that form the 
database are defined via the Data Definition Language (DDL) 
provided by the DBMS, and the programs are created via the 
Data Manipulation Language (DML) . dBASE III provides only one 
language which serves both purposes. 



1 . 



File De-f i n i t i on /Great i on 



The files are defined by using the 'CREATE' dBASE III 
command. This command allows us to define the structure of 
each file to be used by the database system. Since a file is a 
collection of records of the same type, our job here is to 
describe the structure of the records of each file, i.e., the 
attribute (field) names, their types (character, numeric, 
logical, date), and their sizes. Using this command we define 
all “files described above. 

The records of each file are stored in the database by- 
using the command 'APPEND'. Before we use this command we have 
to open the database file the records to be stored in by using 
the command 'USE fn', where 'fn' is the file name. The records 
are stored sequentially in the database file. 

A small number of records for each file has been 
created and stored in the database, so that we will be able to 
test the programs when they have been completed. 

2. Program Creation 

The next step is to write the software which will 
perform the specified functions by manipulating our database 
via the dBASE III DBMS, and producing the required output. 

□ur primary goal is to produce a comprehensi ve working 
system that can be effectively and easily used by people who 
are not programmers. 

The whole program has been decomposed into a number of 
i nterconnected modules in a hierarchical top-down fashion, as 
depicted in the program structure chart in Figure 35. The 
actual programs are presented in APPENDIX A. 



5B 



MAINPROG 




Fig. 35. Program Structure Chart 
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IV. SYSTEM IMPLEMENTATION 



Implementation includes all those activities that take 
place to convert -from the old system to the new. The new auto- 
mated system which has been already developed, is proposed to 
replace the existing manual system. Proper implementation is 
essential to provide a reliable system to meet the specified 
requi rements. 

The aspects o-f implementation which will be discussed here 
include hardware requi rements , training personnel, conversion 
procedures , and so-f tware descr i pti on /document at i on - 



A. HARDWARE REQUIREMENTS 

To implement our system using dBASE III DBMS we need a 
16-bit mi crocomputer using MS DOS or PC DOS version 2.0, or 
later. Any 16—bit mi crocomputer that is -fully so-f tware compa- 
tible with the the IBM PC or IBM PC/XT should be able to use 
the system. The computer must have a minimum o-f 320K of RAM, 
one 20M byte hard— disk drive, and at least one floppy disk 
drive. Any printer that can print SO columns of text can be 
used . 

The RAM is allocated as follows. 

1. About 50K bytes for operating system requirements 
(resident part of DOS). 

2. 180K bytes for the dBASE III system program. 

3. About 16K bytes for the user's program currently being 
executed (this is the size of the biggest program) . 
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4. The rest o-F memory is allocated to the required working 
areas (buffers for the files currently being open). 

In case we want to use another customer— supp 1 i ed program 
(word processor, etc.) along with dBASE III, additional memo- 
ry is required. 

The hard-disk size has been calculated on the basis of a 
full scale-model as follows. 

1. About 130K bytes for the user programs. 

2. About 12M bytes for the required database files and 
index files. These files will contain data for 10,000 
officers (worst case senario). 

3. About 12K bytes for the format files. 

4. About lOOK for text files. 

The rest of the hard-disk space can be used for future 
improvements of the system, as well as for other data storage 
needs. 



B. TRAINING PERSONNEL 

Since the system is implemented on a mi crocomputer , the 
need for training is limited only to a few individuals who 
will be both operators and users- Those individuals who are 
going to use the new system should know how to use a micro- 
computer (how to turn on the system, how to insert a diskette, 
when it is safe to turn off the equipment without danger of 
data loss, or how to determine whether a problem arising is 
caused by the equipment, software or something they have done 
in using the system), what software they will use for the 
system, and how they should use it to perform a specific task. 

As the above discussion demonstr ates , there are two 
aspects to user training: f ami 1 iarization with the processing 
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system itself (equipment used) and training in using the the 
application (that is, the software that accepts the data, 
processes it, and produces the results). Our intent is to 
train a few users how to use the system in order to accomplish 
their task, and not to teach them how to write new programs. 
Therfore, both aspects mentioned above can be covered in a 
very short time period ( one or two weeks). 



C. CONVERSION PROCEDURES 

Conversion is the process of changing the old system to 
the new one. The method we will use for converting from the 
existing manual to the new automated system is the parallel 
systems. That is, the Branch will continue to operate the old 
system in the accustomed manner but it also will begin using 
the new system. This method is the safest conversion approach , 
since it guarantees that if possible errors will arise in 
using the new system (processing errors, inability to handle 
certain types of transact i ons , or other inef f iciencies) they 
will not harm the Branch, since the old system is still in 
use. Another important advantage of the parallel systems ap- 
proach is that before the Branch abandons the manual system, 
there will be a trial period for the new system during which 
revealed errors and inefficiencies can be eliminated without 
loss of time, revenue, or servi ce. CRef . 6: p. 5323 



D . SOFTWARE DESCR I PT I ON / DOCUMENTAT I ON 

The programs which implement our database system have been 
grouped into six categories according to the function they 
perform: main program, main— menu and sub— menu programs, 
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programs supporting the update operations, programs performing 
the assignment processing, programs producing the required 
lists and reports, and miscellaneous programs- All programs 
(code), as well as lists and reports produced by the programs 
are presented in APPENDIX A- 

1 . Mai n Program 

This program * controls the entire operation o-f the 
system and it is the only program that the user calls by name 
(MAINPROG) - After initializing basic dBASE III functions, 
MAINPROG checks if the user is authorized to use the database 
system by prompting him to enter his password- Unauthorized 
users are aborted and the program exits automat i cal 1 y to the 
operating system (DOS), displaying the appropriate message. 

In case the user is an authorized one, MAINPROG calls 
program GRFLAG which displays on the screen the Greek Flag. 
After a small delay it calls program DBSTITLE which provides 
the title of the database system- and prompts the user to hit 
any key to continue- Then program MMENU is called which is the 
main— menu of the system, and pauses waiting for the user to 
make his choice- Then a CASE statement permits the program to 
branch to the appropriate program group according to the users 
choice or exit either to dBASE III or to the underlying 
operating system- A DO WHILE loop causes the process to be 
repeated until the user selects option 4 or 5 in which case 
the program terminates and control passes to dBASE III or to 
the operating system, respect i vel y . 
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2- liai n-Menu and Sub-menu Programs 



a, Main-Menu Program (MMENU) 

This program displays on the screen the main— menu. 
This menu provides a screen of information that shows the user 
what functions can be performed and how to select them. Those 
functions correspond to update operations, assignment proces- 
sing, and report generation. In addition it provides the 
option to exit to either dBASE III or the operating system. A 
flashing label at the top of the menu informs the user that 
the main— menu is on the screen, and a highlighted label at the 
bottom promts him to enter his choice. The user's choice is 
expressed by one of the numeric characters 1 through 9, A 
'RANGE' statement checks each time the user types a character 
and in case it lies outside the specified range an appropriate 
message is displayed. Also the 'PICTURE '9' ' statement 
guarantees that the program does not accept alphabetical or 
other characters. The subsequent sub— menus described below 
work in a similar fashion. 

b. Sub-menu Programs 

Three sub— menus correspondi ng one per basic 
function of the system (update operations, assignment proces- 
sing, report generation) guide the user to perform the appro- 
priate task. Those sub— menus are created by the following 
programs. 

(1) UPDTMENU . This program provides a screen of 
information concerning the update operations. Via this program 
the user can insert, modify, or delete records from the files 
whose names are presented on the screen. UPDTMENU is called 
by the DBUFDATE program in case the user selects option 1 from 
the main— menu. 
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(2) ASPRMENU . This program displays information 
concerning the assignment processing operations. Through this 
program the user can access any of the programs which perform 
the officers' assignments. ASPRMENU is called by the ASSISNTS 
program in case the user selects option 2 from the main-menu. 

(3) RGMENU . This program provides a screen of 
information concerning the report generation operations. From 
this submenu the user can access any of the programs which 
produce the required lists and reports. RGMENU is called by 
the REPORTS program in case the user selects option 3 from the 
mai n— menu. 

3. Programs Supporting the Update Operations 

This group of programs performs all the update opera- 
tions. That is, using these programs we can insert new records 
into the database files, as well as modify or delete existing 
records from the database files- The programs which implement 
those operations are the following: 

a. DBUPDATE 

This program controls the entire update operation 
and is executed whenever the user selects option 1 from the 
main-menu. First the program calls the UPDTMENU program which 
is the update sub— menu we described above, and pauses waiting 
for the user to make his choice which is stored in the vari- 
able 'updtcode'. Then a CASE statement permits the program to 
branch to the correspondi ng update program or exit to main- 
menu. A DO WHILE loop allows the program to keep running until 
the user decides to exit to main-menu. 



b. INSERTOR 



This program allows the user, to insert new records 
into the OFFICER -file which is the main database -file. It is 
called by the DBUPDATE program in case the user selects option 
1 -from the update sub-menu (UPDTMENU program) - 

The program calls the MFRAME program which dis- 
plays a window on the le-ft hal-f o-f the screen into which all 
program messages and user data are placed during the execution 
o-f the program, A message is displayed on the screen prompting 
the user to enter the serial number o-f the o-f-ficer to be 
inserted into the file. Then the program searches the OFFICER 
file using as key the officer's serial number to see whether 
the record exists in the database or not- If the search is 
successful, a message is displayed informing the user that the 
record already exists, and he is asked if there are more 
records to be inserted into the database- In case the search 
operation is unsuccessful (that is, record does not exist in 
the database) the user is asked if he needs the codes required 
for the insert operation (rank, source, specialty, and marital 
status codes) - If his answer is 'Y' (yes) the program WINDQW3 
is called which displays a window occupying the right half of 
the screen containing all codes and their explanation- In this 
way the user can have on-line help and the risk of incorrect 
data input is reduced- Next the format of the record to be 
inserted is displayed on the left frame and the cursor is 
positioned at the first field- 

When the user finishes the input of data for the 
particular officer, the record is appended to the OFFICER file 
and the necessary entries are created in some other database 
files. Namely a record is created into the HISTORIC file 
containing the officer's serial number, the nomination date, 
the order by which the nomination of the officer has been 
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known, and the unit in which he serves- The unit name and the 
order identi-f ication are entered by the user- Then the created 
record is displayed on the screen. Also a record is created 
into the REQUESTS -file containing only the o-f -f -f i cer ' s serial 
number- All other -fields remain empty. In case the source o-f 
the o-f-ficer is 'NCOS' (Non— Commissioned 0-f-ficers School ) , a 
record is created into the SERVES -file containing his serial 
number the unit he serves and the enrollment date. 

A DO WHILE loop keeps the program running as long 
as the user's answer to the prompt 'MORE INSERTIONS? (Y/N) ' is 
'Y' . 



c. INSERTSR 

This program permits the user to insert new 
records into the SCHOOLS -file. No other -files are updated 
during the execution o-f this program- The program is called by 
the DBUPDATE program in case the user selects option 2 -from 
the update sub-menu. 

An o-f-ficer can have more than one record in the 
SCHOOL -file depending on what and how many schools he has gra- 
duated -from. The process goes in a similar way with the 
described above (INSERTOR program) except that the search is 
based on the compound key consisting o-f the -fields serial 
number and school name ( -CSERNO , SCHOOLNAME> ) - The user's answer 
'N' to the program's prompt 'MORE INSERTIONS? (Y/N) ' causes 
the program to be terminated- 

d. INSERTHR 

Through this program the user can insert new 
records into the HISTORIC -file- It is called by the DBUPDATE 
program whenever the user selects option 3 -from the update 



suti-mena. The only legal transactions which can cause new 
records to be inserted into the HISTORIC file from this 
program are those concerning retirement or death. All other 
transactions are aborted by the program. The process is simi- 
lar with that described above. 

e. MODIFYOR 

This program is called by the DBUPDATE program in 
case the user selects option 4 from the update sub— menu, and 
allows him to modify records into the OFFICER file. 

When the program is entered, it calls the MFRAME 
program whose purpose has been explained during the INSERTOR 
program description. Then a message prompts the user to enter 
the serial number of the officer whose record is to be modifi- 
ed. The program searches the OFFICER file using as the key the 
serial number typed by the user. In case of an unsuccessful 
search an appropriate message is displayed and after a small 
delay the user is asked if he wants to perform more modifica- 
tions. If his answer is 'Y' (yes) the process is repeated. In 
the case of a successful search a menu is displayed inside the 
frame created by the MFRAME program that shows the user which 
of the record-f i el ds can be modified and prompting him to 
enter his selection. The fields which can be modified in the 
OFFICER file are the 'NAME', 'RANK' and 'PROMDATE' (promotion 
date), and those concerning the family status ('MARSTAT', 
'CHILDREN', 'WORKWIFE'). After the user's response, the 
structure of the fields to be modified are displayed on the 
screen (inside the frame) and the cursor is positioned at the 
first field. After the displayed fields have been modified by 
the user, the modified record is displayed in an appropriate 
format . 
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In case the rank status has been changed, a record 
in the HISTORIC -file is automatically created including the 
new transaction (PROMOTION) . The new record is displayed on 
the right hal-f o-f the screen in a -formatted way. 

The process keeps going until the user's answer to 
the program's prompt 'MORE MDIFICATIONS? (Y/N) ' is 'N'. 

f. MODIFYRR 

This program allows the user to modi-fy records in 
the REQUESTS -file, and it is called by the DBUPDATE program in 
case the user selects option 5 -from the update sub-menu. All 
-fileds of the records under modification can be changed except 
the serial number which is the primary key. The process is 
similar with that described above, except that it is simpler 
since no other files are updated during the execution of this 
program. The program terminates when the user's answer to the 
program's prompt 'MORE MODIFICATIONS? (Y/N)' is 'N'. 

g. DELETEOR 

Through this program we can delete records from 
the OFFICER file. It is called by the DBUPDATE program when- 
ever the user selects option 6 Trom the update sub-menu. The 
process goes as follows. 

The program calls the MFRAME program (described 
earlier) and prompts the user to type the serial number of the 
officer to be deleted. Then using the serial number as the key 
searches the OFFICER file to find the correspondi ng record. In 
case of an unsuccessful search an appropriate message is dis- 
played and the user is asked if he wants to continue with more 
deletions. If his answer is 'Y' the process is repeated. In 
case of a successful search, the record is displayed on the 
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screen along with the prompt 'DELETE? (Y/N) ' . In this way the 
user has the chance to prevent accidental deletions o-f 
records- I-f the user's answer is 'Y' the record is marked -for 
deletion- Then the program searches the -files HISTORIC, 
SERVES, REQUESTS, and SCHOOLS with the same key, and all 
records that match with the key are marked -for deletion- 

The process keeps going until the user's answer to 
the program's prompt 'MORE DELETIONS? (Y/N)' is 'N'. In this 
case, all -files whi ch . i ncl ude records marked -for deletion are 
packed, and control passes to the DBUPDATE program- 

File packing is a time-consuming operation since 
the entire -file is searched and marked -for deletion records 
are removed- The situation is even worst in case the -file 
is an index one, since a-fter the -file packing the -file is re- 
indexed- For this reason , it is recommended the delete opera- 
tions to be de-f erred until be-f ore the end o-f the user session 
with the system, whenever possible- 

4. Programs PerTorminq the Assignment Processing 

Assignment processing is the most di-f-ficult part o-f 
the system- Two programs -for each rank per-form the assignment 
process- During this process the necessary criteria 
(described during the system's, design) are examined and a 
temporary -file called ASSIGNED is created- This -file contains 
the assignments o-f the o-f-ficers -for each rank- Although these 
programs work in a similar -fashion, we did not write only one 
program to per-form the entire assignments, because this 
program would be very big and dif-ficult to manage- The 
programs and their -function are described below- 
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a. ASSIGNTS 



This program controls the entire assignment pro- 
cessing, and it is called -from the MAINPRQG program whenever 
the user selects option 2 -from the main-menu. The program 
calls the ASPRMENU program (assignment processing sub-menu) 
described earlier, and pauses waiting -for the user to make his 
choice which is stored in the variable 'asprcode'. Then a CASE 
statement allows the program to branch to the correspond! ng 
program and to per-form the assignments -For the particular rank 
or exit to the main— menu. 

b. ASSIGNOl 

This program per-forms the assignments o-F the o-Ffi- 
cers whose rank is '01' (1st lieutenants). It is called by the 
ASSIGNTS program in case the user selects option 1 from the 
assignment processing sub-menu. 

First the program calls the MKAUXFLl program which 
builds the auxiliary -Files FILE3, FILE4, and FILES. The -File 
FILES contains all 1st lieutenants whose last assignment took 
place three or more years be-Fore the present date (system's 
date), their present unit, the requested units for their next 
assignment, and their assignment weights. The other two auxi- 
liary files (FIL6, FILET) are copies of the file FILES. Then it 
calls the WINDOWl program which places a frame on the screen 
into which messages concerning the assignment process are 
displayed, and starts the assignment processing as follows. 

The assignment processing is a two-pass procedure- 
During the first pass the program loops on the file FILET ta- 
king one record at a time and tries to satisfy the requests of 
the officer under examination. That is, it takes the first re- 
quested unit and searches the FILE5 file to find an officer 
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whose present unit is the one requested by the other otficer- 
In case of a successful search, the program searches the FILE6 
file to see if the requested unit is also requested by another 
officer- If it is, then checks the assignment weights- In case 
he has the greatest weight or his assignment weight is equal 
to the greatest assignment weight found and his marital status 
is not equal to 'S' (single), his request is satisfied, his 
record in the FILE6 file is marked for deletion (so that it 
will not be examined during the next loop), the record in the 
FILE5 file is marked for deletion (this means that the reque- 
sted unit has been granted and it cannot be disposed to an- 
other officer), and zero (0) assignment weight is given to the 
officer. This number is going to be added to the total assign- 
ment weight in the correspondi ng field of the OFFICER file la- 
ter- This weight is maintained for each officer during his 
career and it is an important criterion for the assignment 
process- In case one or more. of the conditions described above 
is false the program takes the second requested unit and the 
same process is repeated- If the officer's request for the 
second unit is satisfied, the assignment weight which is given 
him is one (1) this time. Again if the officer's second requ- 
est cannot be satisfied, the program takes the third requested 
unit and the same process is repeated- If his request for the 
third unit is satisfied, the assignment weight is two (2). Fi- 
nally, if none of the three requests has been satisfied during 
the above process, the assignment of the officer is deferred 
for the second pass- The output of the first pass is the crea- 
tion of one record per officer into the ASSIGNED file contain- 
ing among other fields the field 'unitname'- This field, 
in case of a satisfied request contains the name of the new 
unit the officer is assigned to, or an asterisk in the 
case of unresolved assignment. 



During the second pass the auxiliary tile FILES is 
created which has exactly the same structure with the ASSIGNED 
-file but it contains only the unresolved during the -first pass 
assignments (i.e., UNITNAME = Then the program loops on 
this -file taking one record at a time and tries -for another 
time to satis-fy unsatis-fied requests. The process is similar 
with the -first pass. I-f the requests -for an o-f-ficer cannot be 
satis-fied even this time, the program checks the FILE5 -file to 
-find an available unit (not deleted record) in which the 
o-f-ficer can serve according to his source and specialty. In 
the case o-f a success-ful search the contents o-f the 'unitname' 
-field into the ASSIGNED -file -for the correspond! ng o-f-ficer are 
replaced with the unit name -found in FILES, the record in the 
FILES -file is marked -for deletion, and the assignment weight 
three (3) is given to the o-f-ficer. In case o-f an unsuccess-f ul 
search in the FILeS -file, there is no way -for the o-f-ficer to 
be assigned to a new unit during this year, and the corre- 
sponding record into the ASSIGNED -file is marked -for deletion, 

A-fter the last record o-f the FILES tile- has been 
examined and the end o-f -file is encountered, the ASSIGNED -file 
is packed, all the auxiliary -files are deleted, and control 
passes to the ASSIGNTS program. 

c. MKAUXFLl 

This program builds the auxiliary -files FILES, 
FILE6, and FILET which are exactly the same. Those files whose 
use has been explained above are bQilt by combining the basic 
database files OFFICER, SERVES, and REQUESTS (copy and join 
operations). The purpose of those files is to isolate the of- 
ficers under assignment whose rank is '01' (1st lieutenants), 
and who have all the requirements for the assignment process, 
gathering all the data into only three small files. The final 
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result is that by having all required data into -fewer and 
smaller -files we reduce the overhead o-f the search operations 
(FIND, LOCATE, and SEEK) and speed up the processing. 

The program is called by the ASSIGNOl program- It 
calls the program WINDOW which displays on the screen a -frame 
into which messages concerning the process o-f building the 
auj<iliary -files are placed- A-fter the auxiliary -files have 
been created the program terminates and control is passed back 
to the ASSIGNOl program- 

d. ASSIGN02 



This program per-forms the assignments o-f the 2nd 
lieutenants- It is called by the ASSIGNTS program in case the 
user selects option 2 -from the assignment processing sub’-menu. 

The process o-f the program goes in a similar way 
as the ASSIGNOl program with the -following exceptions: 

(1) First, the 2nd lieutenants who graduate -from the 
Military Academy are assigned to the Artillery School 
-for 1-year training- As it is expected no assignment 
weights are examined, neither requests exist- 

(2) Next, the 2nd lieutenants who complete their 1-year 
training in the Artillery School are assigned to the 
Artillery Recruit Training Center- Again no requests or 
assignment weights are examined- 

(3) Then all 2nd lieutenants whose source is the Military 
Academy and who have served’ in the Artillery Recruit 
Training Center are assigned to the combat units in 
which they can serve according to the organization 
table o-f the units. During this process only the 
o-f-ficers' requests are examined, since the assignment 
weight is zero (0) -for all these of-ficers. 

(4) Finally the assignments o-f the 2nd lieutenants whose 
source is the Non-Commissioned Oficers School and who 
have completed the necessary time in the same unit 
(greater than or equal to 3 years) are per-formed- 
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e. MKAUXFL2 



This program is called by the ASSIGN02 program, 
and it builds the required auxiliary -files -for the assignment 
processing o-f the 2nd lieutenants. Its -Function is exactly the 
same as the MKAUXFLl described above. The only difference is 
that the auxiliary files built contain data concerning the 2nd 
lieutenants. The program calls the WINDOWl program, and when 
all the auxiliary files have been built control passes back to 
the ASSIBN02 program. 

f. ASSIGN03 

This program performs the assignments of the 
captains. It is called by the ASSIGNTS program in case the 
user selects option 3 from the assignment processing sub-menu. 
Its function is exactly the same as the ASSIGNOl program 
described earlier. The only difference is that it makes as- 
signments for the captains this time. 

The program first calls the MKAUXFL3, and next the 
WINDOWl programs. After its termination, control passes to the 
ASSIGNTS program. 

g. MKAUXFL3 

This program is called by the ASSIGN03 program du- 
ring the captains' assignment processing. Its structure and 
function is exactly the same as that described in MKAUXFLl. 
The only difference is that the auxiliary files FILES, FILE6, 
and FILET contain data concerning the captains to be assigned. 
The program calls the WINDOW program. After its termination, 
control passes to the ASSIGN03 prqgram. 
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h, ASSIGN04 



This program per-Forms the assignments ot the 
majors and it is called by the ASSIGNTS program in case the 
user selects option 4 -From the assignment processing sub-menu. 
Its structure and -Function is almost the same as the ASSIGNOl 
program with the -Following exceptions. 

(1) First the majors graduating from the War College are 

assigned to staff units within the Branch- Assignment 
weights and officers' requests are taken into 

consi derat i on . 

(2) Next, the rest of majors whose last assignment took 

place two or more years before the present date 

(system's date), are assigned to units inside or 
outside the Branch, or to the War College for training. 
Officers assigned to staff units or to units outside 
the Branch must have graduated from the War College. 
Assignment weights and officers' requests are examined- 
An officer is assigned to the War College for training 
only in case he has been proposed by the Branch- For 
this reason, the file SELECTED is checked each time a 
major's assignment is processed- 

The program calls the NKAUXFL4, and WINDOWl 
programs- When the program terminates, control passes to the 
ASSIGNTS program- 



i . MKAUXFL4 

This program is called by the ASSIGN04 program and 
builds the required auxiliary files for the assignment proces- 
sing of the majors- Its structure and function is similar to 
the MK.AUXFLl program- The program calls the WINDOW program- 
When the program terminates, control is passed to the ASSIGN04 
program- 



j 



ASSIGN05 



This program performs the assignments of the lieu- 
tenant colonels- It is called by the ASSIGNTS program in case 
the user selects option 5 from the assignment processing sub- 
menu. Its structure and function is almost similar to the 
ASSIGNOl program, with the following exceptions- 

(1) The lieutenant colonels can be assigned to units inside 
or outside the-Branch. 

(2) Officers assigned to staff units or to units outside 
the Branch must have completed the requirements for 
their rank, and they must have graduated from the War 
Col 1 ege- 

The program calls the riKAUXFL5, and WINDOW! 
programs- After its termination, control passes to the 
ASSIGNTS program- 

k. MKAUXFL5 

This program is called by the ASSIGNOR program and 
builds the required files for the assignment processing of the 
lieutenant colonels. Its structure and function is similar 
to the MKAUXFLl program- The program calls the WINDOW program. 
When it terminates, control passes to the ASSIGN05 program. 

i: ASSIGNOR 

This program performs the assignments of the colo- 
nels- It is called by the ASSIGNTS program in case the user 
selects option 6 from the assignment processing sub-menu. Its 
function is similar to the ASSIGN05 program- The program 
calls the MKAUXFL6, and WINDOW! programs- When the program 
terminates, control passes to the ASSIFNTS program- 



m. MKAUXFL6 



This program is called by the ASSIGN06 program and 
builds the required auxiliary -Files for the assignment proces- 
sing of the colonels. Its structure and function is similar 
to the MKAUXFLl program. The program calls the WINDOW program. 
After its termination, control passes back to the ASSIGN06 
program. 

Programs Producing the Regui red Li sts and Reports 

All programs producing the required lists and reports, 
have been kept small and simple. Using the report generator- 
facility of dBASE III, you can create report formats up to 80 
columns wide in a very simple way. You simply give a file name 
to the required report , and define its format in the way that 
fits your needs. Defining the format means providing dBASE III 
with the title of the report, the size of the page, spacing, 
number of characters per line, what fields of the records will 
be printed, and what the field headers will be. All the rest 
of the work is done by dBASE III. 

Sample lists and reports produced by the programs 
described below, are presnted in APPENDIX A. 

a. REPORTS 

This program controls the entire operation of this 
group of programs. It is called by the NAINPROG (main program) 
program in case the user selects option 3 from the main-menu. 
First, the program calls the RGNENU program which is the 
report generator sub— menu described earlier, and pauses 
waiting for the user to make his choice which is stored in the 
variable 'repcode''. Then a CASE statement permits the program 
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to branch to the appropriate program within the same group o-f 
programs according to the users choice or exit to the main- 
menu. A DO WHILE loop keeps the program running until the user 
decides to exit to main— menu. 

b. LISTl 

This program is called by the REPORTS in case the 
user selects option 1 . f rom the report generator sub— menu, and 
its purpose is to produce a list o-f the scheduled assignments 
■for some requested rank. First, the program calls the WIND0W2 
program which displays a window on the screen into which 
program messages and user data or answers are placed. A mes- 
sage prompts the user to speci-fy the rank. Then, according to 
the rank the user enters, the program builds the auxiliary 
file AUXFILEl which contains all necessary data for the 
requested list. This file is built by combining the OFFICER, 
REQUESTS, and SERVES file (COPY and JOIN operations). When the 
file is ready, the message 'PRINTER OUTPUT? (Y/N) ' prompts the 
user to specify if he wants a hardcopy printout. If his answer 
is 'Y' (yes), another message is displayed requesting from the 
user to set the printer on and to hit any key to continue. 
Then the program pauses waiting for the user's action. Final- 
ly, the command 'REPORT FORM MKLISTl' causes the requested 
list to be displayed on the screen , or both displayed on the 
screen and printed by the printer. MKLISTl is the format file 
we have defined in the way we described earlier. After this, 
the auxiliary file is deleted and control passes to the 
REPORTS program. 

c. LIST2 

This program is called by the REPORTS program in 
case the user selects option 2 from the report generator 
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sub-menu, and creates a list ot o-fticers serving in some 
requested unit- 

The program's function from the user's side of 
view is similar to the LISTl program described above. The 
difference is that this time, the user is prompted to specify 
the unit name, and that the format file is called MKLIST2. The 
program calls the WIND0W2 program whose purpose has been 
explained in the previous program- After the requested output 
has been produced control passes to the REPORTS program. 

d. LIST3 

This program provides a list of all Artilery offi- 
cers in some requested order- It is called by the REPORTS pro- 
gram in case the user selects option 3 from the report gene- 
rator sub— menu. 

First, the program calls the WIND0W2 program- Then 
a screen of information concerning the possible orders is dis- 
played inside the window, and a message prompts the user to 
select the order he likes (by seniority, al phabet i cal 1 y , by 
specialty, etc-)- According to the users choice, a CASE 
statement allows the program to select the appropriate index 
file- We do not use the 'SORT' dBASE III command to sort a file 
in some order, because it is time and space consuming. 
Instead, we use existing index files which are always 
presented in the order of the field on which they are indexed- 
In all other aspects the program works in the same way as the 
LISTl and LIST2 programs except that the format file is called 
MKLIST3 this time. 

e. LIST4 

This program is called by the REPORTS program in 
case the user selects option 4 from the report generator 
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sLib-menu. 



The pr ogram produces a 1 i st o-f o-F-ficers o-f some 
requested rank- The process goes exactly in the same way as 
the LISTl program- The format -file is called MKLIST4- 

f. LISTS 

This program produces a list of the Artillery bat- 
talion commanders, and it is called by the REPORTS program 
in case the user selects option 5 from the report generator 
sub-menu- During its execution the user is asked to specify 
only the device on which he wants the output (screen or print- 
er)- The format file is called MKLISTS- In all other aspects 
the process goes exactly in the same way as in LISTl program- 

g. LIST6 

This program is called' by the REPORTS program in 
case the user selects option 6 from the report generator sub- 
menu- The program provides a list of all officers serving out- 
side the Branch- The report file is called MKLIST6- The user 
is asked by the program to specify only the device on which 
he wants the output- The program works in the same way as the 
LISTS program- 

h. REPORT 1 

This program creates the service time report for 
any requested officer- This report contains all the major- 
transactions of an officer occurring during his career- It is 
called by the REPORTS program in case the user selects option 
7 from the report generator sub-menu. The program searches the 
HISTORIC file and prints out or displays on the screen in an 
appropriate format all records whose key matches with that 
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typed by the user when he was asked by the program to enter 
the o-Fficer's serial number- 

i . REP0RT2 

This program is called by the REPORTS program in 
case the user selects option 8 from the report generator sub- 
menu- It provides a status report for any requested officer. 
This report contains all information on an officer's current 
status. The database files which are searched are the OFFICER 
and SERVES. 

Mi seel 1 aneous Programs 

This group includes all programs which do not perform 
any processing of data- Their purpose is to provide formatted 
messages, and display windows on the screen, required during 
the database processing- These programs are the following: 

a. GRFLAB 

This program is called by the MAINPROG (main 
program) , and forms on the screen the Hellenic Flag. 

b. DELAY 

This program is called by most of the programs du- 
ring the processing, and makes various program messages stay- 
ing on the screen for a certain time period. 

c- DBSTITLE 

This program is called by the MAINPROG program and 
displays on the screen the database system title- 
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d 



MFRAME 



This program is called by the INSERTOR, MODIFYOR, 
and DELETEOR programs, and it displays a -frame on the le-ft 
hal-f o-f the screen into which messages and formatted records 
are placed. 

e. FRAME 

This program is called by the INSERTOR and 
MODIFYOR programs, and displays a small window into which for- 
matted records from the HISTORIC file are placed. 

f. WINDOW 

This program is called by the MKAUXFLl, MKAUXFL2, 
MKAUXFL3, MKAUXFL4, MKAUXFL5, and MKAUXFL6, and its purpose is 
to display a window on the screen, into which messages inform- 
ing the user about the processing, are displayed. 

g. WINDOWl 

This program is called by the ASSIGNOl, ASSIGN02, 
ASSIGN03, ASSIGN04, ASSIGN05, and ASSIGNOR programs during the 
assignment processing, and it serves the same purpose as the 
the previous program. 

h- WINDDW2 

This program is called by the LISTl , LIST2, LIST3, 
LIST4, LISTS, LIST6, REPORTl, and REP0RT2 programs, and it 
provides the same function as the WINDOW program. 
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WINDOWS 



i . 



This program is called by the INSERTOR program in 
case the user's answer to the program's prompt 'DO YOU NEED 
CODES? (Y/N) ' is 'Y'- The program provides a window on the 
right halt o*f the screen into which all codes concerning rank, 
source, specialty, and marital status, required during the 
insertion ot new records into the OFFICER -file, are displayed. 
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V. CONCLUSIONS AND RECOMMENDATIONS 



This thesis develops a personnel database system model, 
suitable for implementation within the Artillery Branch 
Directorate of the Hellenic Army General Staff. This system 
could also be applied to any Branch Directorate with minor 
modifications. 

The main goal is to increase product i vi ty , effectiveness, 
accuracy, and speed, as far as personnel management is 
concerned, as well as to decrease the national expenditure, 
and release manpower for other purposes. Additionally, the 
Branch Director will be able to make faster and better inform- 
ed decisions concerning personnel. 

dBASE III was used as the DBMS, since it is a relational 
model, which is simple and understandabl e , increases independ- 
ency, reduces redundancy, and it is very popular in the micro- 
computer world. In addition, dBASE III contains its own pro- 
gramming language, which is a high level structured language, 
very efficient for data mani pul at i on . 

I have implemented the officers' assignment processing, 
and the most usually needed lists and reports, but a wide va- 
riety of other reports, or simple queries could also be 
created. Emphasis was given to provide simple and user friend- 
ly programs, in order to help the users of the system and make 
their job easier. 

The software life cycle has been taken into account during 
the program development. Since there was no previous experi- 
ence on the topic of assignment processing, and no concrete 
specifications about the organization of the units (the tables 
used are figurative), I have decided to follow the prototyping 
approach in order to create the programs. This means that some 
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o-f the programs may need -further improvements. This can be 
done in close cooperation with the Branch, which will be the 
actual user of the system- Programs have been kept small and 
are easily modified to meet future improvement needs- In this 
application I have used the top-down design approach which 
serves the above goal . 

In this implementation I have used files whose records 
include a certain amount of data. Further improvements might 
add more fields in the records, so that the system can provide 
expanded inf ormati on . 

This thesis constitutes a good basis for further improve- 
ments in the area of personnel management and especially in 
the field of automation of the officers' assignment processing 
in the Hellenic Army- 
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APPENDIX A 



DATABASE SYSTEM PROGRAMS 



A. MAIN PROGRAM 



******************* PROGRAM MAINPROG ********************* 

* This is the main program, which controls the operation o-f 

* the entire database system 

CLEAR 

* Initialize basic dBASE III functions 
SET TALK OFF 

SET DELIMITER OFF 
SET HEADING OFF 
SET EXACT ON 

* Declare global variables 
PUBLIC psw 

STORE ' ' TO psw 

a 10,18 SAY ' IKMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMK, ' 
a 11,18 SAY 'L9 L9' 

a 12,18 SAY 'HJMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMJ c; ' 

* Check user's authorization 

a 11,30 SAY 'ENTER PASSWORD ->' 

SET CONSOLE OFF 
ACCEPT TO psw 
SET CONSOLE ON 
USE userid 

LOCATE FOR password = UPPER (psw) 

* Unauthorized user. Exit to operating System 
IF EOFO 

SET COLOR TO W* 

a 11,28 SAY ' UNAUTHORIZED USER 
DO delay 
SET COLOR TO W 
QUIT 
END IF 

* Authorized user 
STORE .T. TO continue 
DO grflag 

DO delay 
DO dbstitle 
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DO WHILE continue 
DO mmenu 

* perform appropriate function depending on user' 
DO CASE 

CASE selection = 1 
DO dbupdate 
CASE selection = 2 
DO assi gnts • 

CASE selection = 3 
DO reports 
CASE selection = 4 

STORE .F. TO continue 
CASE selection = 5 
QUIT 

ENDCASE 

ENDDO 

SET TALK ON 
SET DELIMITER ON 
SET EXACT OFF 
SET HEADING ON 
CLEAR ALL 
RETURN 



Choi ce 
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B. MAIN-MENU AND SUB-MENU PROGRAMS 



1 . Main-Menu program 

********************* PROGRAM MMENU ********************** 



* This program displays the system main-menu on the screen 
CLEAR 

PUBLIC selection 
STORE O TO selection 

a 4,18 SAY ' IKMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMK, ' 
a 5,18 SAY 'L9 L9' 

a 6,18 SAY 'HJMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMJ< ' 
SET COLOR TO W* 
a 5,35 SAY 'MAIN MENU' 

SET COLOR TO W 



a 




18 


SAY 


' IMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM, ' 


a 


8, 


18 


SAY 


/ 






/ 


a 




18 


SAY 


/ 


DATABASE UPDATE: 


1 


/• 


a 


10, 


18 


SAY 


/ 


ASSIGNMENT PROCESSING: 




/ 


a 


11, 


18 


SAY 


/ 


REPORT GENERATOR: 


. - . - 3 




a 


12, 


18 


SAY 


/ 


END OF DATABASE SESSION: 






a 


13, 


18 


SAY 


/ 


EXIT TO DOS: 


5 


/ 


a 


14, 


18 


SAY 


/ 






/ 


a 


15, 


18 


SAY 


/ 


. 




/ 


a 


16, 


18 


SAY 


/ 






/ 


a 


17, 


18 


SAY 


'HMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM 


/ 



SET COLOR TO W+ 

a 15,29 SAY 'ENTER YOUR SELECTION ->: ' , 

GET selection PICTURE '9' RANGE 1,5 
READ 

SET COLOR TO W 
RETURN 
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2. Sub— Menu Programs 



♦*********-»-******** PROGRAM UPDTMENU **************-»-»-»-«-)«-»-)(- 
* This ptogram displays on the screen the update sub-menu 
CLEAR 

PUBLIC updtcode 
STORE 0 TO updtcode 

a 4,18 SAY ' IKMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMK, ' 
a 5,18 SAY 'L9 L9' 

a 6,18 SAY 'HJMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMJC ' 

SET COLOR TO W* 
a 5,35 SAY 'UPDATE MENU' 

SET COLOR TO W 



a 


7,18 


SAY 


' iMMmmMmMmMMMMmMMMmmMMMMMMmmmmMmM , 


/ 

» 


a 


8,18 


SAY 


/ 














/ 


a 


9,18 


SAY 


/ 


INSERT 


RECORDS 


INTO 


OFFICER 


FILE: . . . 


. . 1 


/ 


a 


10,18 


SAY 


/ 


INSERT 


RECORDS 


INTO 


SCHOOLS 


FILE; . . . 




/ 


a 


11,18 


SAY 


t 


INSERT 


RECORDS 


INTO 


HISTORIC 


FILE: . . 


- - 3 


/ 


a 


12,18 


SAY 


/ 


MODIFY 


RECORDS 


FROM 


OFFICER 


FILE: . . . 


- - 4 


/ 


a 


13,18 


SAY 


/ 


MODIFY 


RECORDS 


FROM 


REQUESTS 


FILE: . . 




/ 


a 


14,18 


SAY 


/ 


DELETE 


RECORDS 


FROM 


OFFICER 


FILE: . . . 




/ 


a 


15,18 


SAY 


t 


EXIT TO MAINMENU: . . . 








/ 


a 


16, 18 


SAY 


t 














/ 


a 


17,18 


SAY 


f 


- 












/ 


a 


18,18 


SAY 


t 














/ 


a 


19,18 


SAY 


' HMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM^ 


r* / 



SET COLOR TO W+ 

a 17,29 SAY 'ENTER YOUR SELECTION , 

GET updtcode PICTURE '9' RANGE 1,7 
READ 

SET COLOR TO W 
RETURN 
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********************* PROGRAM ASPRMENU 



********■»**■)<•*#*****■» 



* This program displays on the screen the assignment proces- 

* sing sub-menu 



CLEAR 

PUBLIC asprcode 
STORE 0 TO asprcode 



a 4,18 SAY ' IKMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMliMMK, 
a 5,18 SAY 'L9 L9 

a 6,18 SAY 'HJMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMr- 1 J< 
SET COLOR TO W* 

a 5,28 SAY 'ASSIGNMENT PROCESSING MENU' 

SET COLOR TO W 

a 7,18 SAY ' IMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM, 



a 8,18 SAY ': 

a 9,18 SAY ': 1st LIEUTENANT ASSIGNMENT PROCESSING:..! 

a 10,18 SAY ': 2nd LIEUTENANT ASSIGNMENT PROCESS ING: . . 2 

a 11,18 SAY ': CAPTAIN ASSIGNMENT PROCESSING: 3 

a 12,18 SAY ': MAJOR ASSIGNMENT PROCESSING: 4 

a 13,18 SAY ': LIEUT. COLONEL ASSIGNMENT PROCESSING: .. 5 

a 14,18 SAY ': COLONEL ASSIGNMENT PROCESSING: 6 

a 15,18 SAY ': EXIT TO MAIN MENU: 7 

a 16,18 SAY ' : 
a 17,18 SAY ': 
a 18,18 SAY ' : 



a 19,18 SAY 'HMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMC 
SET COLOR TO W+ 

a 17,29 SAY 'ENTER YOUR SELECTION ->', 

GET asprcode PICTURE '9' RANGE 1,7 



READ 

SET COLOR TO W 
RETURN 
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*^****************** 



PROGRAM R6MENU 



*****-»•»*■»•*****•♦****•*• 



* This program displays on the screen the report generator 

* sub— menu 



CLEAR 

PUBLIC repcode 
STORE 0 TO repcode 



a 3,14 SAY ' IKMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMK, 
a 4,14 SAY 'L9 L9 

a 5,14 SAY 'HJMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMJ:; 
SET COLOR TO W* 

a 4,30 SAY 'REPORT GENERATOR MENU' 

SET COLOR TO W 

a 6,14 SAY ' IMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM, 



a 7, 14 SAY ' : ; 

a 8,14 SAY ':LIST OF SCHEDULED ASSIGNMENTS: 1: 

a 9,14 SAY ':LIST OF OFFICERS OF A SPECIFIC UNIT: 2: 

a 10,14 SAY ':LIST OF OFFICERS IN ANY DESIRED ORDER: 3: 

a 11,14 SAY ':LIST OF OFFICERS OF A SPECIFIC RANK: 4: 

a 12,14 SAY ':LIST OF BATTALION COMMANDERS: 5: 

a 13,14 SAY ':LIST OF OFFICERS SERVING OUTSIDE THE BRANCH:. 6: 

a 14,14 SAY ': OFFICER'S SERVICE TIME REPORT: 7: 

a 15,14 SAY ': OFFICER'S STATUS REPORT: 8; 

a 16,14 SAY ':EXIT TO MAIN MENU: 9: 

a 17,14 SAY ': : 

a 18, 14 SAY ' : : 

a 19,14 SAY ' : : 



a 20,14 SAY 'HMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMC 
SET COLOR TO W+ 

a 18,27 SAY 'ENTER YOUR SELECTION ->', 

GET repcode PICTURE '9' RANGE 1,9 



READ 

SET COLOR TO W 
RETURN 
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C. PROGRAMS SUPPORTING THE UPDATE OPERATIONS 



********************* PROGRAM DBUPDATE *-»-»*******'»-»^(^*-»***-»»* 

* This program controls the system's update operations 

CLEAR 

STORE ' ' TO updtcont 

PUBLIC updtcode 
DO WHILE updtcont # 'n' 

DO updtmenu 
DO CASE 

CASE updtcode = 1 
DO insertor 
CASE updtcode = 2 
DO insertsr 
CASE updtcode = 3 
DO inserthr 
CASE updtcode = 4 
DO modi-fyor 
CASE updtcode = 5 
DO modifyrr 
CASE updtcode = 6 
DO deleteor 
CASE updtcode = 7 

STORE 'n' TO updtcont 

ENDCASE 

ENDDO 

RETURN 
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**********■)(•****•»•»•»** PROGRAM INSERTOR 



******************** 



* This program adds records to OFFICER file, updates all other 

* affected database files, as well as records log-data into 

* USERLOB file 



CLEAR 

STORE 'y' TO insertcont 



* open required for the processing database files 
SELECT 1 

USE historic INDEX historic 
SELECT 2 

USE requests INDEX requests 
SELECT 3 

USE officer INDEX officer 

SELECT 4 

USE userid 

SELECT 5 

USE user log 

SELECT 6 

USE serves INDEX serves 
STORE -F. TO done 

DO WHILE UPPER (insertcont) = 'Y' 

SELECT 3 
DO mframe 

a 3,5 SAY 'INSERT NEW RECORD TO OFFICER FILE' 
a 4,5 SAY 'MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM' 



* Initialize memory variables 



STORE ' ' TO 

STORE ' ' TO 

STORE ' ' TO 

STORE ' ' TO 

STORE ' ' TO 

STORE ' ' TO 

STORE ' ' TO 

STORE ' ' TO 

STORE ' ' TO 

STORE ' ' TO 

STORE ' ' TO 

STORE ' ' TO 

STORE ' ' TO 

STORE 0 TO 

STORE .F. TO 



a 20,7 SAY 'ENTER SERIAL NUMBER 
READ 



tuni t 
border 

tname 

tserno 

trank 

tnomyear 

tspec 

t source 

ndate 

pdate 

tci ty 

tcounty 

tmarst 

tchi 1 d 

twwi f e 

->' GET tserno 

PICTURE '99999' 
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* check whether record exists into OFFICER -file 
FIND 2'.tserno 
IF EOFO 

* record does not exist 
a 20,7 SAY ' 

STORE ' ' TO answer 

a 12,45 SAY 'DO YOU NEED CODES? (Y/N) ==>' GET answer 
READ 

IF UPPER (answer) = 'Y' 

DO window3 
ELSE 

a 12,45 CLEAR 
ENDIF 



* 


read 


user 


's data 'form the 


keyboard 




a 




SAY 


'name : 


: ' GET 


tname 












P I CTURE ' AA AAAAAAAA AA AAAAAA ' 


a 


6,5 


SAY 


'serial # 


' GET 


tserno PICTURE 


' 99999 ' 


a 


7,5 


SAY 


' rank 


' GET 


trank PICTURE ' 


99 ' 


a 


8,5 


SAY 


'nomination year 


' GET 


tnomyear PICTURE '99' 


a 


9,5 


SAY 


' speci al ty 


' GET 


tspec PICTURE ' 


A' 


a 


10,5 


SAY 


' source 


' GET 


tsource PICTURE 


: 'AAAA' 


a 


1 1,5 


SAY 


'nomination date 


' GET 


ndate 












PICTURE '99/99/99' 




a 


12,5 


SAY 


'promotion date : 


: ' GET 


ndate 












PICTURE '99/99/99' 




a 


13,5 


SAY 


'origin (city) : 


: ' GET 


tcity PICTURE ' 


XXXXXX' 


a 


14,5 


SAY 


'origin (county): 


i ' GET 


tcounty 












PICTURE 'XXXXXXXX' 




a 


15,5 


SAY 


'marital status : 


: ' GET 


tmarst PICTURE 


'A' 


a 


16,5 


SAY 


' # o-f chi 1 dren : 


: ' GET 


tchild PICTURE 


'9' 


a 


17,5 


SAY 


'working wi-fe’? : 


i ' GET 


twwi-fe 





READ 

* append new record to OFFICER -file 
APPEND BLANK 

REPLACE name WITH tname, serno WITH tserno 
REPLACE rank WITH trank, nomyear WITH tnomyear 
REPLACE specialty WITH tspec , source WITH tsource 
REPLACE asnweight WITH 0 nomdate WITH CTOD(ndate) 
REPLACE promdate WITH CTOD(ndate), origcity WITH tcity 
REPLACE origcounty WITH tcounty, marstat WITH tmarst 
REPLACE children WITH tchild, workwi-fe WITH twwi-fe 
STORE .T. TO done 

* create an etry into REQUESTS -file 
SELECT 2 

FIND ?<t serno 
IF EOFO 

APPEND BLANK 

REPLACE serno WITH tserno 
ENDIF 
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♦ add record to SERVES tile it otticer's source is NCOS 
IF tsource = 'NCOS' 

SELECT 6 
FIND ?<tserno 
IF EOFO 

STORE ' ' TO tun it 

a 20,7 SAY 'ENTER UNIT NAME -> ' SET tunit 
READ 

APPEND BLANK 

REPLACE serno WITH tserno,uni tname WITH tunit,, 
enrol date WITH CTOD(ndate) 

END IF 
ENDIF 



* add record to HISTORIC tile (transact, is NOMINATION) 
SELECT 1 

STORE 'NOMINATION ' TO trans 
SEEK tserno + trans + ndate 
IF EOFO 

STORE ' ' TO torder 

a 20,5 SAY 'ENTER ORDER- >' GET torder 
READ 

a 20,5 SAY ' 

APPEND BLANK 

REPLACE serno WITH tserno, rank WITH trank,, 

transtype WITH trans , transdate WITH CTOD (ndate) , , 
orderid WITH torder,unit WITH tunit 
a 2,45 CLEAR 



* display new record ot 



DO trame 
a 11,45 SAY 
a 12,45 SAY 
a 13,45 SAY 
a 14,45 SAY 
a 15,45 SAY 
a 16,45 SAY 
ELSE 



'serial #: ' 
'rank : ' 
' transac. : ' 
'unit : ' 
'date 

'order : ' 



HISTORIC tile 

GET serno 
GET rank 
GET transtype 
GET unit 
GET transdate 
GET orderid 



? '*** ERROR: RECORD EXISTS IN HISTORIC FILE' 



DISPLAY 
DO delay 
a 22,0 CLEAR 
ENDIF 



♦ record exists into OFFICER tile and cannot be added again 
ELSE 

a 20,6 SAY ' RECORD ALREADY EXISTS 
DO delay 
ENDIF 
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a 20,6 SAY ' MORE INSERTIONS? (Y/N) ->' 

SET CONSOLE OFF 
WAIT TO insertcont 
SET CONSOLE ON 
CLEAR 
ENDDO 

* record log-data into the USERLOS -file 
IF done 

SELECT 4 

LOCATE FOR password = UPPER (psw) 

SELECT 5 
APPEND BLANK 

REPLACE username WITH D->username, task WITH ' INSERTION ^ 
progname WITH ' INSERTOR ' , 1 ogdate WITH DATE ( ) , , 
log time WITH TIMEO 

END IF 

CLOSE DATABASES 
RETURN 
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■It****************** 



PROGRAM INSERTSR ********************* 



* This program adds new records to SCHOOLS file, 

* the USERLOG file 



and 



CLEAR 



* open required for the processing files 
SELECT 1 
USE userid 
SELECT 2 
USE user log 
SELECT 3 
USE officer 
SELECT 4 
USE schools 



INDEX officer 



window on the screen 

' I MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM . 



MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM 



* display a 
3 4,20 SAY 

a 5,20 SAY 
a 6,20 SAY 
a 7,20 SAY 
a 8,20 SAY 
a 9,20 SAY 
a 10,20 SAY 
a 11,20 SAY 
a 12,20 SAY 
a 13,20 SAY 
a 14,20 SAY 
a 15,20 SAY 
a 16,20 SAY 

a 17,20 SAY 'HMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM< 
STORE 'y' TO insertcont 
STORE .F. TO done 

DO WHILE UPPER (insertcont) = 'Y' 

a 5,24 SAY 'INSERT NEW RECORD TO SCHOOLS FILE' 



* initialize memory variables 



STORE ' 
STORE ' 
STORE ' 
STORE ' 
STORE ' 
STORE 0 
STORE ' 
a 16,26 SAY 

READ 



' TO tserno 

' TO tschname 

' TO tdegree 

' TO tobject 

' TO tcountry 

TO tduration 
' TO tgdate 

'ENTER SERIAL NUMBER ->' GET tserno 

PICTURE '99999' 



updates 



98 



* check i -f record exists in OFFICER -file 
SELECT 3 
FIND ?<tserno 
IF .NOT. EOFO 

* record exists in OFFICER -file 

♦ check i-f the record to be added exists in SCHOOLS -file 

a 1(£),26 SAY ' ENTER SCHOOL NAME GET tschname 

READ 

SELECT 4 

LOCATE FOR serno = tserno .AND. school name = tschname 



IF 



EOFO 

♦ record does not exist in SCHOOLS -file 



* read user 
a 16,26 SAY 
a 7,23 SAY 
a 8,23 SAY 
a 9,23 SAY 
a 10,23 SAY 
a 11,23 SAY 
a 12,23 SAY 

a 13,23 SAY 



keyboard 



s data -from the 
/ 

'serial 4 
' school —name 
' degree 
'object o-f studies: 
'country : 

'duration : 

'graduation date : 



GET tserno 
GET tschname 
GET tdegree 
GET tobject 
GET tcountry 
GET tduration 
PICTURE '99' 

GET tgdate 
PICTURE '99/99/99' 



READ 



* append new record to SCHOOLS -file 
APPEND BLANK 

REPLACE serno WITH tserno, school name WITH tschname, 
degree WITH tdegree, object WITH tobject,, 
country WITH tcountry, duration WITH tduration,, 
graddate WITH CTOD (tgdate) 

STORE .T. TO done 

* record exist in SCHOOLS -file 
ELSE 

a 16,26 SAY 'RECORD ALREADY EXISTS 
DO delay 
END IF 

♦ record does not exist in OFFICER -file, and we cannot 

* add new recor to SCHOOLS -file 
ELSE 

a 16,21 SAY 'RECORD DOES NOT EXIST IN OFFICER FILE' 

DO delay 
a 16,21 SAY ' 

END IF 

a 16,26 SAY 'MORE INSERTIONS? (Y/N) ->' 

SET CONSOLE OFF 
WAIT TO insertcont 
SET CONSOLE ON 
ENDDO 
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* update USERLOG -file 
IF done 

SELECT 1 

LOCATE FOR password = UPPER (psw) 

SELECT 2 
APPEND BLANK 

REPLACE username WITH B->username, task WITH 'INSERTION',, 
progname WITH ' INSERTSR ' , 1 ogdate WITH DATE ( ) , , 
logtime WITH TIMEO 

END IF 

CLOSE DATABASES 
RETURN 
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**■»*■»-»*********■»*■»* PROGRAM INSERTHR ****■*•****■»*****■)<•***■)(••» 

* This program adds new records to HISTORIC -file, and updates 
•» USERL06 -file 



serves 



hi stor i c 



CLEAR 

* open required -for the processing -files 
SELECT 1 

USE serves INDEX 
SELECT 2 

USE historic INDEX 
SELECT 3 

USE o-f-ficer INDEX o-fficer 

SELECT 4 

USE userid 

SELECT 5 

USE user log 

STORE 'y' TO insertcont 

a 2,17 SAY 'THE ONLY LEGAL TRANSACTIONS 

a 3,17 SAY ' CAN BE ADDED FROM THIS 

SET COLOR TO 
a 4,17 SAY ' 

a 5,17 SAY ' 

SET COLOR TO 
STORE .F. TO 
SELECT 2 

DO WHILE UPPER (insertcont) = 'Y' 

* display window on the screen 



FOR WHICH A RECORD' 
PROGRAM ARE: ' 



W+ 



W 

done 



RETIREMENT' 
DEATH ' 



a 7 , 


18 


SAY 


' I MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM , 


/ 


a 8, 


18 


SAY 


/ 




INSERT RECORDS INTO HISTORIC FILE 


/ 


a 9, 


18 


SAY 


/ 




MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM 


/ 


a 10 , 


18 


SAY 


/ 






/ 


a 11 , 


18 


SAY 


/ 






/ 


a 12 , 


18 


SAY 


/ 






f 


a 13, 


18 


SAY 


/ 






/ 


a 14, 


18 


SAY 


/ 






/ 


a IS, 


18 


SAY 


/ 






/ 


a 16 , 


18 


SAY 


/ 






/ 


a 17, 


18 


SAY 


/ 






/ 


a 18 , 


18 


SAY 




• f 


* initial ize 


memory varibles 




STORE 


.F. TO 


dupl i cate 




STORE 


/ 




/ 


TO 


tserno 




STORE 


/ 


/ 




TO 


trank 




STORE 


/ 








' TO trans 




STORE 


/ 






/ 


TO tdate 




STORE 


/ 








' TO torder 




a 17, 


20 


SAY 


'ENTER SERIAL NUMBER ->' GET tserno 





READ 



PICTURE '99999' 



101 



